Method and System for Auditing Advertising Agency Performance

ABSTRACT

Computerized techniques are disclosed for automatically converting buy data from advertising agencies into a common format for storage in a database. The commonly formatted buy data can be automatically analyzed to assess advertising agency performance in executing advertising plans on behalf of their client companies. The buy data can be representative of original buys, final buys, and/or actual buys.

CROSS-REFERENCE AND PRIORITY CLAIM TO RELATED APPLICATIONS

This application is a continuation of pending U.S. patent applicationSer. No. 11/253,040, filed Oct. 18, 2005 and entitled “Method and Systemfor Reconciling Advertising Invoices and for Providing Prompt PaymentTherefor”, now U.S. Pat. No. _____, which is a continuation-in-part ofU.S. patent application 10/810,466, filed Mar. 26, 2004 and entitled“Method and Apparatus for Auditing the Performance of AdvertisingAgencies on Behalf of Their Clients”, the entire disclosures of each ofwhich are incorporated herein by reference.

FIELD OF THE INVENTION

The parent invention relates to a technique whereby advertising agenciesare audited to analyze their performance in connection with executingadvertising plans for their clients.

The present invention relates to a technique whereby advertisinginvoices can be promptly reconciled. The improved reconciliation alsoallows for prompt and accurate payment to media properties foradvertising services that have been rendered.

BACKGROUND OF THE INVENTION

Companies typically utilize one or more advertising agencies to deviseand implement one or more advertising plans on their behalf. In theseplans, advertising agencies typically identify a number of goals andother information related to the plan. As used herein, the termadvertising agency encompasses all business entities that engage in thepractice of media buying.

For example, the plans will typically identify the media in whichadvertisements will run. Examples of media include but are not limitedto television, radio, and print. The choice of the actual mediaproperties, as well as the time and place in which the advertisementswill run, is generally left to the discretion and expertise of theadvertising agency. Examples of media properties include but are notlimited to television networks, specific television stations, radiostations, newspapers, and magazines.

Further, the plans will typically identify the markets in whichadvertisements will run. Often, markets are identified in terms ofdesignated market areas (DMAs). DMAs are well known in the field ofadvertising and typically encompass a core city and the surroundingarea. Examples of DMAs include but are not limited to the St. Louis DMA(which would encompass the city of St. Louis, Mo. and nearby surroundingcommunities in Missouri and Illinois) and the Miami/Fort Lauderdale DMA(which would encompass the cities of Miami, Fla. and Fort Lauderdale,Fla. as well as their nearby surrounding communities). Depending uponthe scope of the advertising plan, multiple DMAs may be targeted by anadvertising agency when executing a client's advertising plan.

Further, advertising plans will typically identify a target demographicand a desired level of exposure for that target demographic. A commontarget demographic for companies engaged in mass market sales is the age18-49 demographic. However, as would be understood, the targetdemographic can be particularized according to virtually any trait,including but not limited to different age classifications, gender,occupation, heritage, income level, political preference, etc. Exposurelevels for television and radio advertising are typically expressed interms of target rating points (TRPs). One TRP is well-known in the artto be one percentage point of the number of people estimated to beviewing a television/radio spot versus the number of people who could beviewing the television/radio spot. For example, if market A includes100,000 people who could be watching television and an advertisement isrun on a particular TV channel at a time when 50,000 people in market Aare watching that channel, that advertisement will have achieved 50TRPs. Exposure levels for print advertising are typically expressed interms of circulation for the print item.

Advertising plans will typically identify a target number of total TRPsand/or a total amount of circulation desired for various advertisementsduring a specified time period (year, quarter, month, etc.). The budgetfor an advertising plan can then be expressed in terms of cost per TRPor cost per thousands of circulation (CPM), wherein a total cost for theadvertising plan is expressed as the sum of (1) a total number of TRPsdesired multiplied by the average cost of a TRP, and (2) a total amountof desired circulation (in the thousands) multiplied by an average CPM.

Once the expected cost for the advertising plan is calculated by theadvertising agency and approved by the client, the advertising agencysets out to purchase the plan. Agencies execute clients' advertisingplans by purchasing advertisement time/space with media properties. ForTV/radio ads, advertisement times are usually requested in terms ofdayparts. A daypart is a component of a day that relates to a specifictime period. Dayparts are well known in the art, and common daypartsinclude, but are not limited to: morning, daytime, early fringe, earlynews, prime access, prime, late news, weekend, sports, etc. However, itshould be noted that different entities may use different definitionsfor daypart components. For example, one media property may considerearly fringe to begin at 4:30 pm CST and end at 5:00 pm CST, while aparticular advertising agency may consider early fringe to extend from4:00 pm CST to 5:00 pm CST. For print ads, advertisement placement isusually specified in terms of page placement.

The advertising agency's initial attempt to purchase advertisementtime/space with media properties can be referred to as an original buy.Media properties generally have the final say on what gets aired, andmedia properties will often shuffle advertisement requests or fail toair advertisement requests included in the original buy for a variety ofreasons (scheduling demands, better offers coming along, etc.).

After the shuffling settles following the original buy, the advertisingagency places its final buy with the various media properties. Finalbuys correspond to final requests for advertisement spots placed withmedia properties by an agency. Once again, there is no guarantee thatall elements of the final buy will be carried out as desired by theadvertising agency because the media properties may make furtheralterations. The cost for a final buy is typically based on the cost perspot for the time at which the advertisement is to run.

Once the advertisements actually run, data corresponding to these actualadvertisements are expressed in the actual buy. The actual buy TRP valuefor each actual advertisement can be determined from independent sourcessuch as Nielsen TV ratings and Arbitron radio ratings, and representsthe number of TRPs achieved by the airing.

As for costs, media properties typically bill advertising agencies fortheir clients' advertisements at the end of the standard broadcast month(based on a final Sunday per month cycle). The agencies typicallyreceive their bills from the media properties by the 20^(th) of themonth following the previous month's activity. Clients are typicallypre-billed by the agencies throughout this process. Pre-billing to theclient from the advertising agency typically occurs the first day of themonth of the purchased activity, and the pre-bill is based on theestimated costs for the month billed. The portion of the client'spayment to the agency that is to be applied to media property invoicesis deposited in a financial account by the agency. As invoices arereceived from media properties and verified for accuracy by the agency,payments are made to media properties for their invoices from thefinancial account. Billed costs in media property invoices are typicallybased on unit costs as generated by the media property. Unit cost istypically a derivative of the estimated target rating point (TRP)multiplied by the cost per rating point.

It is believed by the inventors herein that a typical account receivabletime period in the advertising industry for payment to media propertieson media property invoices received by advertising agencies is around 90days. During this lengthy account receivable period, the client's money(which was pre-billed by the agency) sits in the account maintained bythe agency, where it earns interest. This interest is typically kept bythe agency and represents a perk for agencies that creates adisincentive for prompt payment of media property invoices. It isbelieved by the inventors herein that the interest on these accountsamounts to a yearly boon to the advertising agency industry upward of$40 billion.

This interest is believed to represent a “hidden” cost to clients ofadvertising agencies. That is, due to the time value of money, the delaythat media properties experience in connection with payment of theirinvoices effectively results in a loss of potential income to the mediaproperties, which is believed to translate into higher advertisingprices being passed on to clients.

Accordingly, the inventors herein believe that a need exists in the artfor a new system that can decrease the delay experienced between thetime a media property advertising invoice is received and the time thatthe media property advertising invoice is reconciled and paid.

Also, in the past, attempts to accurately audit the performance ofadvertising agencies in carrying out the advertising plans of theirclients throughout the process described above have been difficult.

Often, the advertising agency would provide its client with a self-auditof its own performance. However, due to the conflicts of interestinherent in such self-audits, these audits have not proven valuable toclients as an objective measure of an agency's performance because, moreoften than not, the self-audits would inevitably establish a wonderfulperformance by the agency.

With respect to independent advertising agency audits conducted byunbiased third parties, the task of assembling an audit report hasproven to be a gargantuan task requiring tedious efforts by teams ofauditors. To perform such an audit, these auditors are required to porethrough and make sense of volumes of paper documents that relate toadvertisement postings by advertising agencies. Because of the massivemanpower required for these efforts and because of the unsatisfactorylack of detail and flexibility in these conventional independent auditreports, the inventors felt there was a great need in the art for animproved method of objectively auditing advertising agencies to evaluatetheir performances in executing their clients' advertising plans.

SUMMARY OF THE INVENTION

To fill such needs, the inventors herein have designed a system wherebya repository of data relating to agencies' executions of clients'advertising plans is maintained. From this repository, audit reports canbe automatically generated that detail the agencies' performances onbehalf of their clients.

According to one aspect of the parent invention, disclosed herein is amethod of auditing an advertising agency to evaluate how the agencyperformed in executing an advertising plan on behalf of a client, themethod comprising: (1) storing data that describes the advertising plan;(2) storing data that describes a plurality of actual advertisements,each actual advertisement corresponding to at least one clientadvertisement placed by the agency that was run by at least one mediaproperty; and (3) processing the stored plan data and the stored actualadvertisements data to generate data indicative of whether the actualadvertisements satisfied the advertising plan. The processing step ofthe method preferably comprises obtaining exposure data for the actualadvertisements data from an independent source such as Nielsen ratingsor Arbitron ratings and then matching the actual advertisements datawith the exposure data obtained therefor. Further still, the methodpreferably further comprises generating a report from the generated datafor delivery to the client. Such reports include not only paper reportsprinted from the generated data but also visual displays of thegenerated data such as those displayed on a computer monitor. The levelof detail and the flexibility in the level of detail available in thegenerated reports is set forth in greater detail below.

According to another aspect of the parent invention, disclosed herein isa method of creating a database of data for evaluating how a pluralityof advertising agencies perform on behalf of their clients, each clienthaving at least one advertising plan that at least one of theadvertising agencies has attempted to implement, the method comprising:(1) receiving data describing a plurality of actual advertisements,actual advertisements being advertisements placed by agencies with aplurality of media properties on behalf of the clients that wereactually run by the media properties, the actual advertisements datahaving a plurality of formats; (2) converting the received actualadvertisements data to a common format; and (3) storing the convertedactual advertisements data in a database for subsequent use in an auditof at least one advertising agency for at least one client.

The inventors herein further disclose a system for determining an amountof money to be transferred to a media property in satisfaction of aninvoice from that media property, the system comprising: an invoicereconciliation system configured to automatically reconcile a pluralityof invoice items with a plurality of final buy items to determine anamount of money to be transferred, preferably electronically, to themedia property in satisfaction of the invoice items, each invoice itemcorresponding to an actual advertisement spot that was run and invoicedby the media property, each final buy item corresponding to anadvertisement spot request that was placed by the advertising agencywith the media property.

This invoice reconciliation system can be further configured to (1)identify a plurality of invoice items for which an exception handlingcondition applies, and (2) provide at least one graphical user interface(GUI) for display to a user, the at least one GUI being configured tointeract with the user about at least one invoice item for which anexception handling condition has been identified, the interactionincluding receiving input from the user corresponding to an action to betaken on the at least one invoice item.

A significant challenge in developing an invoice reconciliation systemfor media property invoices in the advertising industry relates to theability of such a reconciliation system to be cross-platform in terms ofthe different software packages that many advertising agencies and mediaproperties use in connection with the final buy and invoice activities.Accordingly, the inventive system preferably also includes a conversionsystem and a database in communication with the conversion system andthe invoice reconciliation system, wherein the conversion system isfurther configured to (1) receive the invoice items in a first format,(2) receive the final buy items in a second format, (3) convert at leastthe received final buy items to a format in common with the invoiceitems, and (4) store the invoice items and the converted final buy itemsin the database, and wherein the invoice reconciliation system isfurther configured to retrieve a plurality of the stored invoice itemsand a plurality of the stored final buy items prior to performingreconciliation.

Moreover, the invoice reconciliation system is preferably furtherconfigured to communicate money transfer authorization instructions to acomputer system that controls the disbursement of funds to pay mediaproperty invoices, the money transfer authorization instructionsidentifying at least (1) the determined amount of money to betransferred to the media property and (2) the media property to whichthe determined money amount from the account is to be transferred.

According to another aspect of the present invention, the inventorsherein disclose a computer-implemented method of reconciling mediaproperty invoice data for advertising services with advertising agencyfinal buy data, the media property invoice data comprising a pluralityof invoice items, each invoice item corresponding to an actualadvertisement spot that was run by the media property, the final buydata comprising a plurality of final buy items, each final buy itemcorresponding to an advertisement spot request that was placed by theadvertising agency with the media property, the method comprising: (a)comparing the invoice items with the final buy items, and (b) responsiveto the comparing step, identifying the invoice items for which a paymentto the media property is authorized. Corresponding software forperforming this method is also disclosed herein.

According to yet another aspect of the present invention, the inventorsherein disclose a computer-implemented method of creating commonlyformatted media property invoice data for advertising services andadvertising agency final buy data, to thereby allow reconciliation ofthe media property invoice data with the advertising agency final buydata, the media property invoice data comprising a plurality of invoiceitems, each invoice item corresponding to an actual advertisement spotthat was run by the media property, the final buy data comprising aplurality of final buy items, each final buy item corresponding to anadvertisement spot request that was placed by the advertising agencywith the media property, the method comprising: (a) receiving theinvoice items in a first format, (b) receiving the final buy items in asecond format, and (c) performing at least one of the steps selectedfrom the group consisting of (1) converting the received final buy datato a common format, (2) converting the received invoice data and thereceived final buy data to a common format, (3) converting the receivedinvoice data to the second format, and (4) converting the received finalbuy data to the first format. Corresponding software for performing thismethod is also disclosed herein.

These and other features and advantages of the parent and presentinventions will be in part apparent and in part pointed out in thefollowing description, referenced figures, and appendices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an overview of the preferred embodiment of the presentinvention;

FIG. 2 depicts a preferred invoice reconciliation system;

FIG. 3 is a flowchart overview for creating a database of commonlyformatted invoice data and final buy data;

FIG. 4 depicts an exemplary data format for raw final buy data;

FIG. 5 depicts an exemplary data format for invoice data;

FIG. 6 is a flowchart illustrating a preferred process for reconcilingthe invoice data with the converted final buy data;

FIG. 7 is a flowchart detailing step 604 of FIG. 6;

FIGS. 8( a)-(f) illustrate various preferred exception handling GUIs;

FIG. 9 depicts a preferred GUI for viewing a list of messages receivedby a media property user;

FIGS. 10( a) and (b) depict various preferred GUIs for a media propertyuser to respond to a request submitted via the GUIs of FIGS. 8( a)-(f);

FIG. 11 depicts an overview of the preferred embodiment of the presentinvention;

FIG. 12 depicts a preferred user interface for entering plan data andoriginal buy data into the database;

FIG. 13 depicts a preferred user interface for entering data relating toan analysis of costs per media property;

FIG. 14 is a flowchart overview for the auditing process for thepreferred embodiment of the parent invention;

FIG. 15 depicts an exemplary data format for raw final buy data;

FIG. 16 depicts an exemplary data format for raw posted buy data;

FIG. 17 is a flowchart illustrating the processing for recoding rawdaypart data;

FIGS. 18( a)-(c) depict an example of a mapping table for recoding rawdaypart data;

FIG. 19 depicts a preferred user interface for overriding theindependent exposure data for an advertisement posting;

FIG. 20( a)-(e) illustrate various preferred user interfaces forgenerating audit reports;

FIGS. 21( a)-(d) illustrate various preferred market analysis auditreports;

FIG. 22 illustrates a preferred average ratings audit report;

FIGS. 23( a)-(c) illustrate various preferred CPP audit reports;

FIGS. 24( a)-(d) illustrate various preferred under delivery trackingaudit reports;

FIGS. 25( a)-(h) illustrate various other preferred audit reports;

FIGS. 26-68 illustrate a sample audit report for TV/radio; and

FIGS. 69-278 illustrate a sample audit report for print media.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Parent U.S. patentapplication Ser. No. 10/810,466

FIG. 11 depicts an overview of the preferred embodiment of the parentinvention. The auditing system 1100 comprises a computer 1102 thatreceives raw data relating to advertisement buys for clients byadvertising agencies 1108. This raw data is preferably received from theagencies electronically over a network such as the Internet. However,any known form of communication can be used to communicate the raw datato the auditor, including leased data lines and mailings from agenciesto the auditor. However, transmission of the data to the auditor in theform of paper copies is not preferred as it requires intervention by theauditor to perform manual entry of the raw data into a database. It isbelieved that through various negotiations between agencies, agencyclients, and the auditor, advertising agencies can be persuaded toutilize electronic transmission of the raw data to the auditor.Preferred transmission techniques include e-mail and file uploads over anetwork, such as http uploading over the Internet.

The auditor preferably maintains a computer 1102 and database 1104 toperform the auditing functions of the preferred embodiment of the parentinvention. The computer is preferably a commercially-available DellPoweredge 2650, and the database is preferably a commercially-availableMicrosoft MS SQL 2000. It should be understood that the computer 1102and database 1104 can be implemented with other hardware, including animplementation as a personal computer, workstation, or server that canbe accessed over a network such as the Internet. As will be explained ingreater detail below, the database 1104 serves as a repository for thedata used in the auditing process. The computer 1102 preferably providesthe programming logic, or code segments executable by a processor, forperforming the audit. This programming logic can reside on memory ofcomputer 1102 or on a device such as a compact disc (CD) or the like tobe accessed by computer 1102 from a disk drive or the like. Also, thisprogramming logic preferably includes a code segment for displaying andcontrolling a graphical user interface 1106 that is configured tointeract with a user to manage the auditing process and, if necessary,provide data entry functionality. Preferred tasks for the user interface1106 are to provide the user with the ability to add data to thedatabase 1104 as appropriate and to provide the user with control forgenerating the audit reports of the preferred embodiment.

The auditor for the preferred embodiment of the parent invention ispreferably a party or entity independent from the advertising agenciesbeing audited. By virtue of this independence, clients can be reassuredas to the unbiased nature of the audit results. However, as should beunderstood by those of ordinary skill in the art, an advertising agencyand/or an advertising agency client can also practice the invention byserving as the auditor themselves.

In one embodiment, access to the user interface 1106 is restricted tothe independent auditor. However, in another embodiment, some or alltasks of the user interface can be implemented on a client's computersuch that the client has remote access over a network such as theInternet to the computer 1102 and database 1104. This embodimentprovides clients with the power to generate audit reports without goingthrough a third party auditor. In such an embodiment, it is preferredthat the computer 1102 or a server that controls access to computer 1102implement conventional security measures to maintain the integrity ofclients' data in the database 1104 by restricting a client's access tothe database to its own data. Further still, in another embodiment, theuser interface can also be implemented on an agency's computer such thatthe agency has remote access over a network such as the Internet to thecomputer 1102 and database 1104, thereby providing agencies with thepower to generate audit reports of themselves. This embodiment alsopreferably involves the computer 1102, or a server that controls accessto computer 1102, implementing conventional security measures thatprevents an agency from gaining access to data unrelated to that agency.

Creating the Database of Audit Data:

One aspect of the preferred embodiment relates to storing data thatdescribes the agency advertising plans in the database. The advertisingplan, which is typically communicated by the agency to the client inwriting, generally specifies on a quarterly basis: the markets in whichads are to run, a target demographic for the plan, a desired number ofTRPs for each daypart in the market that are to be achieved by the plan,and a total cost for the plan. Once the auditor receives such plan data,the auditor preferably uses the interface 1350 of FIG. 12 to store theplan data in the database. However, as should be understood, the plandata can also be communicated to the computer 1102 electronically fromeither the client or the agency.

With reference to FIG. 12, the auditor preferably enters a clientidentifier such as a client's name in field 1222. Further, the auditorpreferably enters an agency identifier such as an agency's name in field1224. The DMA for the plan is preferably entered in field 1226, theduration for the plan (typically measured in terms of quarters, althoughother durations, such as monthly, can also be used) in field 1228, andthe target demographic in field 1230. Further still, the auditorpreferably enters an identifier for the advertising plan in field 1232and a total cost for the plan in field 1234.

Row 1236 is set aside for entering TRP data for the plan by daypart,with each daypart corresponding to a different column 1240 a through1240 o. If the agency (or client) does not provide TRP data for the planthat is broken down by daypart, the interface 1350 preferably includesan override control feature 1242. By checking box 1242 a and entering anaggregate sum of TRPs for all dayparts identified for the plan in field1242 b, the auditor can directly enter the aggregate TRP sum in thedatabase.

Once the auditor has completed entry of the plan data, the databaseincludes an important point of reference for performing an audit on theadvertising agency.

Another aspect of the preferred embodiment relates to storing originalbuy data in the database. Advertising agencies typically provide clientswith original buy data on a quarterly basis. This original buy data isoften communicated in paper form, thus requiring further data entry bythe auditor to get the data into the database. However, as should beunderstood, the agency or the client can communicate the original buydata to the auditor electronically as explained below in connection withthe final buy data and the actual buy data. The interface 1220 of FIG.12 can also be used by the auditor to enter original buy data into thedatabase. Row 1238 is set aside for entering TRP data for the originalbuy by daypart, with each daypart corresponding to a different column1240 a through 1240 o. If the agency (or client) does not provide TRPdata for the original buy that is broken down by daypart, the interface1350 preferably includes the override control feature 1242 as describedabove. Once the auditor has completed entry of the original buy data,the database includes another point of reference for performing an auditon the advertising agency.

FIG. 13 corresponds to a user interface for entering data relating to ananalysis of costs per media property. The auditor preferably enters datafor the client, the agency, the

DMA, the target demographic, the time duration, and the plan in fields1352, 1354, 1356, 1358, 1360, and 1362 respectively. Further, each row1374 corresponds to data for a different media property identified by anidentifier, such as station call letters, in column 1364. For each mediaproperty, the interface 1350 provides a field in column 1366 for a timeduration (preferably by month, although other time periods can be used),a field in column 1368 for the total cost of the original buy for theplan, a field in column 1370 for the amount of money billed to theagency by the media property for the plan (affidavit data), and a fieldin column 1372 for the amount of money remitted by the agency to themedia property for the plan (remittance data).

FIG. 14 is a flowchart overview for the auditing process for thepreferred embodiment of the parent invention. At step 1400, the raw datarelating agencies' final buys and actual buys are received from theagencies (preferably electronically). Each agency may store the finalbuy data and/or the actual buy data in different formats depending uponthe software packages used by the agencies. Examples of industry-usedformats for the final buy data and the actual buy data are the DDSformat (1400 a) for media buy software from Donovan Data Systems, Inc.,the Strata format (1400 b) for media buy software from Strata Marketing,Inc., the Adware (1400 c) format for software from AdWare Systems, Inc.,and the SmartPlus format (1400 d) for software from the companyMarketing Resources Plus. It should be noted that other data formats mayalso be used in the practice of the invention.

FIG. 15 illustrates a sample format for a final buy data file that wouldbe received electronically from an advertising agency in the preferredembodiment of the parent invention. The final buy data can be providedas a flat file, as a relational database structure, or other known formsfor maintaining data. In the example of FIG. 15, the final buy data ispresented as a flat file through table 1500, with each table rowcorresponding to a different advertisement spot that was requested bythe agency and each column including pertinent data for thatadvertisement spot.

With reference to FIG. 15, data in column 1502 identifies the media inwhich the advertisement spot is to run. The data in column 1504identifies the client. The data in column 1506 provides an identifierfor the product/service that corresponds to the advertisement. The datain column 1508 provides an identifier code for the plan corresponding tothe advertisement spot, and the data in column 1510 provides the name ofthe plan corresponding to the advertisement spot.

Further, the data in column 1512 identifies the beginning and end datesfor the final buy request (expressed by week). The data in column 1514identifies the DMA in which the final buy was requested, the data incolumn 1516 identifies the media property with which the final buyrequest was placed, and the data in column 1518 identifies a line codefor the media property. The line code serves as a reference to theadvertising agency buy line, as is known in the art.

Further still, the data in column 1518 identifies the program duringwhich the advertisement spot is to run, the data in column 1520identifies the daypart code for the time during which the advertisementspot is to air, the data in column 1522 specifies the length (inseconds) for the advertisement spot, the data in column 1524 specifiesthe scheduling rotation by day for the program, and the data in column1526 identifies the air time for the program. Moreover, the data incolumn 1528 identifies the cost for the advertisement spot, and the datain column 1530 identifies an estimation by the agency of the amount ofexposure for the advertisement spot (in terms of a total number of TRPsthat the agency thinks the advertisement spot will achieve if it runsduring a commercial break for the program). Columns 1532, 1534, and 1536each correspond to a particular week during the time period identifiedin column 1512. The data in each of these columns identifies the numberof advertisement spots requested for that program during the specifiedweek. Lastly, the data in column 1538 includes any comments that anagency may wish to include for the advertisement spot. For example, theagency may want to note as a comment that the spot was aired to makegood on an earlier missed spot, that a spot's tardy airing was due to asports program running long, or that a spot's airing was pre-empted bynews war coverage.

It should be noted that the final buy data format of FIG. 15 isexemplary only. Different advertising agencies will often use differentformats. As a result of this diversity, the final buy data received by apractitioner of the parent invention is expected to have a wide varietyof formatting differences. For example, two agencies may use the samefields for their data, but provide those fields in a differentsequential order. Also, some of the fields used by one agency may not beused by another agency (e.g., one agency provides a field for “line”data (column 1518 in FIG. 15, while another agency does not). Also, twoor more agencies may use different formats for the data that populatesthe fields (e.g., Agency A codes dates numerically as mm/dd/yy(12/31/03) while Agency B codes dates alphanumerically as month name,month date, year (Dec. 31, 2003); Agency A codes dayparts with a twoletter code, Agency B codes dayparts with a three letter code, andAgency C codes dayparts with a four letter code). Further still, whenthe final buy data is provided as electronic files, some agencies mayprovide the final buy data in a relational database format, while othersmay supply the data in a flat file format, while yet others may supplythe data in other known electronic data structures.

FIG. 16 illustrates a sample format for an actual buy data file thatwould be received electronically from an advertising agency in thepreferred embodiment of the parent invention. This actual buy datapreferably arrives as invoices from the agencies, although this need notbe the case. For example, some agencies could conceivably provide theactual buy information as a report separate from their invoices. As withthe final buy data, the actual buy data can be provided as a flat file,as a relational database structure, or other known forms for maintainingdata. In the example of FIG. 16, the actual buy data is presented as aflat file through table 1600, with each table row corresponding to adifferent advertisement spot that was run by a media property (an actualadvertisement) and each column including pertinent data for that actualadvertisement.

The data in columns 1602, 1604, 1606, 1608, 1610, 1612, and 1614correspond, respectively, to the data in columns 1502, 1504, 1506, 1508,1510, 1514, and 1516 in the final buy data of FIG. 15. The data incolumn 1616 identifies the date on which the actual advertisement ran,and the data in column 1618 identifies the day on which the actualadvertisement ran. The data in column 1620 identifies the time at whichthe actual advertisement ran, and the data in column 1622 identifies thelength (in seconds) for the actual advertisement. The invoiced cost forthe actual advertisement is identified in column 1624 and the invoicenumber is identified in column 1626. Lastly, the data in column 1628identifies the film code for the actual advertisement. The film code ispreferably defined by industry standards as known in the art.

It should be noted that, as with the final buy data, the actual buy dataformat of FIG. 16 is exemplary only. Different advertising agencies willoften use different formats, as explained above in connection with FIG.15.

Because of the diversity in the final buy data and the actual buy datareceived from the agencies (this received data can be referred to as rawfinal buy data and raw actual buy data), the parent invention preferablyconverts the received raw data to a common format to greatly simplifythe processing logic used to audit the data stored in the database.Accordingly, the programming logic for performing the audit need notaccount for each individual raw data file format, thereby enhancing themodularity of the auditing logic to provide for increased flexibility inthe event the auditing logic is to be altered, or in the event that anew format for raw data is received.

A practitioner of the parent invention can select the common format forthe conversion step 1402 of FIG. 14 as a design choice based on apersonal evaluation of the facts and circumstances relating to thesystem. For example, the common format can be one created by theauditor. The common format can also be one of the existing “raw” formats(such as Strata or DDS), which would reduce the translational burden andallow other processing steps to utilize off-the-shelf software (such assteps 1410 and 1412 discussed below). However, as facts andcircumstances may dictate, some practitioners of the parent inventionwho do not want to be limited to the use of such off-the-shelf softwaremay find it more agreeable to develop their own common format. Further,the data structures for the common format may be selected to bestructures for a relational database to facilitate storage usingwell-known database language techniques, or it can be a flat file formatfor practitioners of the parent invention who are less comfortable withrelational databases.

Once the practitioner of the parent invention identifies the raw dataformats and common data format involved in the conversion process, amapping table for mapping raw data values for each of the fields in theraw data file records in the various exemplary file formats 1400 athrough 1400 d into the common format can be generated using ordinaryskill in the art. This mapping table can then be used in performing theconversion step 1402.

One preferred aspect of the raw data conversion is the enforcement ofstandardized coding for the data fields (step 1402 of FIG. 14). One ofthe data fields that is preferably standardized is the daypart codefield for the raw data. Each file format often uses different daypartcodes to express the same daypart.

FIG. 17 illustrates the process for daypart recoding. At step 1700, theformat for the daypart code data for a buy record in a file isidentified. Then, at step 1702, the process performs a look-up in adaypart mapping table for an entry that matches the daypart code of theidentified format. FIG. 18 illustrates an exemplary daypart codingmatching table 1800. The data in column 1802 identifies the format forthe mapping table entry 1810, the data in column 1804 identifies a knowndaypart code for the format of column 1802, the data in column 1806identifies the standardized daypart code for that entry, and the data incolumn 1808 identifies the media type for the entry.

If step 1704 finds a matching entry in column 1804 of the table 1800 forthe format of column 1802, then at step 1706, the daypart code isreplaced by the standardized code in column 1806 of the matching entry.Thereafter, at step 1708, the process moves on to the next daypart codein the raw data file and the process begins anew.

If step 1704 does not find a matching entry in the daypart mappingtable, the process proceeds to step 1710. At step 1710, an auditor ispreferably prompted with a user interface that requests manual entry ofa replacement daypart code. To facilitate the auditor's task, the userinterface preferably identifies the file format for the daypart codedata, the actual daypart code, the program corresponding to the daypartcode from the same buy record of raw data, the day(s) of the week anddate(s) for the entry in the same row of raw data, and the time for theprogram. From this data, the auditor will be able to determine theappropriate replacement daypart code and enter that code through theinterface. At step 1712, the replacement daypart code received from theauditor replaces the raw daypart code, and at step 1714, the mappingtable 1800 is updated with the new replacement daypart code data.Accordingly, the mapping table 1800 is a “learning” table that isupdated as new daypart code translations are needed. Over time, it wouldbe expected that the route through the flow of FIG. 17 will follow moreand more the automated path of steps 1700-1708, bypassing the auditorintervention steps of 1710-1714.

Further, it is preferable that other aspects of the raw data bestandardized, such as the DMAs, media property identifiers, anddemographic classifications. Likewise, the technique of FIG. 17 can beused for mapping data value of these data fields as well.

With reference to FIG. 14, the output of the conversion step 1402 willbe an import/export file 1404 for the converted final buy data and theconverted actual buy data. This file will be in the common format.Thereafter, at step 1406, this common format file 1404 is imported intoa database to create a database 1408 of converted final buy andconverted actual buy data.

Thereafter, at step 1410, the content of the database 1408 is processedto determine whether the advertisement spots in the final buy data matchwith the actual advertisements in the actual buy data. This step isperformed by attempting to match entries in the final buy data withentries in the posted buy data and vice versa. Matching and non-matchingentries are flagged accordingly.

Further, at step 1411, the data values of data fields in the database1408 are recoded as necessary to provide uniform standards for data fromdifferent agencies. It is within the judgment of a practitioner of theinvention as to which fields will have their data values standardized.However, it is preferred that the daypart codes assigned to the recordsin the final buy data and actual buy data be standardized at step 1411.As previously noted, different agencies often use different definitionsfor dayparts such that the time period covered by Agency A's “earlyfringe” daypart may be different than the time period covered by AgencyB's “early fringe” daypart. Thus, at step 1411, it is preferred that thefinal buy and actual buy daypart records be substantively re-evaluatedusing a standard set of daypart definitions based at least in part ontime of day, day, and date. This standard set of daypart definitions ispreferably client-specified, although this need not be the case. In acurrent implementation, the auditor manually evaluates and recodes (ifnecessary) the dayparts assigned to the final buy and actual buyrecords. However, it should be noted that this step can also beautomated.

Next, at step 1412, the process obtains exposure data for the actualadvertisements from an independent source. This exposure data ispreferably expressed in terms a number of TRPs achieved for an actualadvertisement. There are a number of well-known commercial sources forindependent exposure data, such as A.C. Nielsen for TV ratings data andArbitron for radio ratings data. The entries for each actualadvertisement are thereafter updated with the exposure data, thuscreating database 1414 of advertisement postings data (or posted buydata).

Additionally, it is preferred that step 1412 also include obtaining SpotQuotation and Data (SQAD) data that pertains to TRP costs. SQAD data iswell-known and commercially-available in the art. This SQAD data can beentered in the database manually, although as should be understood, thisneed not be the case. It is also preferred that step 1412 includeobtaining NSI average ratings data, which is also commercially-availablein the art. This NSI data can also be entered in the database manually,although this need not be the case. Further still, the obtaining of theSQAD data and the NSI data need not be limited to step 1412, as the SQADand NSI data can also entered into the database at other times,unrelated to the flow of FIG. 14.

The creation of software code for steps 1410 and 1412 is within theskill of ordinary programmers. However, it should be noted that softwareis commercially available for performing these tasks. Suitablecommercially-available software platforms for performing steps 1410 and1412 are available from Strata Marketing, Inc., CORE, TvScan (formerlyknown as TAPSCAN, Inc., and now a part of Marketron International),Marketing Resources Plus, Donovan Data Systems, Inc., and AdWareSystems, Inc., as is known in the art.

In some cases, an advertising agency, a client, or a media propertydisagrees with the independent TRP value assigned to a particular actualadvertisement. Typically, the TRP provided by the independent sourcerepresents a measure based at least in part on a ¼ TRP achieved by aprogram for a certain time period. Such ¼ hour TRPs may not take intoaccount the special circumstances of a particular airing of the program.For example, if the program during which an actual advertisement ran wasa baseball game for a team based in the applicable DMA, the ¼ hour TRPmeasure for that team's games may be much lower than a TRP achieved whena game with the team's archrival is aired. In such circumstances, theagency/client/media property may request that the independent TRP amountfor the program be overridden with a different measure. To achieve thisfunctionality, the preferred embodiment of the parent invention includesthe interface 1900 of FIG. 19.

Through interface 1900, the auditor preferably can specify theapplicable client, agency, DMA, target demographic, time duration, andmedia property in fields 1902, 1904, 1906, 1908, 1910, and 1912respectively. In field 1914, the auditor can pull up the name of theprogram applicable to the inquiry (i.e., the name of the program duringwhich the actual advertisement ran). Once the applicable program isidentified, its estimated TRP value from the final buy data ispreferably displayed in field 1918 and its “actual” TRP value from theindependent source is preferably displayed in field 1920. Through field1922, the auditor can provide an adjustment of the “actual” TRP value.Further, the auditor can provide the reason(s) for the adjustment in the“comments” field 1924. Further still, if the auditor would like toremove an adjustment made to the “actual” TRP value for an advertisementposting, he/she can do so using the “delete adjustment” button 1916.

Database 1414, together with the database(s) into which the plan dataand the original buy data were stored, form the audit database 1104.Database 1104 can be implemented as a single database or can beimplemented as several distributed databases according to the preferenceof a practitioner of the invention.

The database 1104 serves as a valuable repository for analyzing theperformance of advertising agencies when executing the advertising plansof their clients. From the content of database 1104, audit reportsdetailing the agency performances from a variety of analyticalperspectives can be generated. For example, the reports can identify theperformance of multiple agencies for a single client (for those clientshaving multiple advertising agencies working on their behalf). Further,the reports can audit agency performance by DMA for advertising plansthat stretch into more than one DMA. The audit reports can beparticularized down to virtually any field in the content of database1104.

Creating Audit Reports:

Step 1416 relates to the processing logic configured to generate suchaudit reports. The creation of the logic for generating audit reportsfrom the database contents will be apparent to a programmer withordinary skill in the art who follows the teachings herein with respectto the database and audit reports. The generation of audit reports ispreferably initiated by the auditor through user interfaces as shown inFIGS. 20( a)-(e). However, it should be noted that the system can alsobe designed to generate each of the reports automatically, with theautomatically generated reports being stored for subsequent retrieval.Also, the report generating logic can be implemented on either thecomputer 1102, a client computer that has access to the computer 1102,or some other computing device in communication with computer 1102.

FIG. 20( a) illustrates a preferred user interface 2000 for generatingmarket analysis audit reports. Through selection of the “marketanalysis” tab 2002, the auditor is presented with fields 2012, 2014, and2016 in which he/she is to specify the client, time period (preferablyquarter, although other time durations may be used), and advertisingagency for the audit. Further, the interface 2000 may preferably includefield(s) (not shown) for specifying the applicable DMA and/ordemographic group for the report. Preferably, each field can bepopulated through drop down menus that are pre-loaded with the clients,time durations, and agencies already present in the database. Further,as any fields are filled, it is preferred that the range of choices inthe drop down menus be further limited based on the previousselection(s). For example, if Client A is selected in field 2012, thenit is preferred that the drop down menu for the agency field 2016 belimited to agencies already associated with Client A in the database.Further still, it is preferred that if the auditor selects a report forwhich certain conditional qualifiers are not needed (e.g. with the MultiAOR DMA Delivery reports corresponding to options 2008 and 2010, theauditor need not specify an agency in field 2016), then the conditionalfields of interface 2000 be restricted accordingly.

Further, the auditor can specify the type of market analysis auditreport that is to be generated, with checkbox 2004 corresponding to a“Market Analysis (Intl)” report, checkbox 2006 corresponding to a“Market Analysis (DMA Delivery Recap) (Intl)” report, checkbox 2008corresponding to a “Market Analysis (Multi AOR DMA Delivery—pcnt)(Intl)” report, and checkbox 2010 corresponding to a “Market Analysis(Multi AOR DMA Delivery—TRP (Intl)” report. Selection of the “generatereport” button 2018 by the auditor causes the selected market analysisreport for the selected client/quarter/agency to be generated.

FIG. 21( a) illustrates an exemplary market analysis report 2100 thatcorresponds to box 2004 of FIG. 20( a). The report identifies theclient, advertising agency, DMA, target demographic, and time durationin fields 2102, 2104, 2106, 2108, and 2110 respectively to which thereport is pertinent. This data corresponds to the selections made by theauditor through the user interface 2000.

The report preferably includes a daypart analysis for the advertisingplan and plan execution that indicates whether the advertising agencysatisfied the exposure goals for the plan. Each row 2112 a through 2112o corresponds to a different daypart. Column 2114 includes the TRPvalues for each daypart from the plan data stored in the database, asdescribed above in connection with FIG. 12. Column 2116 includes the TRPvalues for each daypart from the original buy data stored in thedatabase, as also described above in connection with FIG. 12. Further,column 2118 includes the TRP values for each daypart from the final buydata. These TRP values are taken from entries in the received final buyfiles for the specified conditions 2102-2110, as converted and recodedby step 1402 of FIG. 14. As previously noted, the TRP values of column2118 correspond to the agency's estimations of the amount of exposureexpected for an advertisement. Further still, column 2120 includes theposted TRP values for each daypart obtained from an independent sourceincluding TRP value overrides (if any) provided by the auditor. The TRPvalues of column 2120 correspond to the actual TRP values assigned tothe actual advertisements by an independent source.

With this base of TRP data, the report preferably also displays aplurality of indicators that identify how the agency's performance inexecuting the plan compares with the plan. Further, the reportpreferably displays an indicator of how closely the posted buy datamatches with the final buy data.

Column 2122 preferably displays, for each daypart, an index comparingthe amount of TRPs in the original buy with the amount of TRPs in theplan. This index is preferably displayed as a percentage and can becomputed as 100 times the number of TRPs for that daypart in theoriginal buy divided by the number of TRPs for that daypart in the plan.

Column 2124 preferably displays, for each daypart, an index comparingthe amount of TRPs in the final buy with the amount of TRPs in the plan.This index is preferably displayed as a percentage and can be computedas 100 times the number of TRPs for that daypart in the final buydivided by the number of TRPs for that daypart in the plan.

Column 2126 preferably displays, for each daypart, an index comparingthe amount of TRPs in the posted buy (the actual buy plus the thirdparty exposure data, as possibly adjusted through an override) with theamount of TRPs in the plan. This index is preferably displayed as apercentage and can be computed as 100 times the number of TRPs for thatdaypart in the posted buy divided by the number of TRPs for that daypartin the plan.

Lastly, column 2128 preferably displays, for each daypart, an indexcomparing the amount of TRPs in the posted buy with the amount of TRPsin the final buy. This index is preferably displayed as a percentage andcan be computed as 100 times the number of TRPs for that daypart in theposted buy divided by the number of TRPs for that daypart in the finalbuy.

2130 preferably includes the sum for each daypart TRP value of columns2114, 2116, 2118, and 2120. Further, the total index values for columns2122, 2124, 2126, and 2128 are preferably calculated from these summedvalues.

The audit report 2100 further preferably includes a stewardship analysissection 2132 that breaks down the financial data for the various buys bymedia property in the applicable DMA. Each row 2134 a through 2134 fcorresponds to a different media property (identified by columns 2136(call letters) and 2138 (network affiliation)) in the applicable DMA.The media property-specific original buy data in column 2142, affidavitdata in column 2146, and remittance data in column 2150 is readilyavailable in the database as described above in connection with FIG. 13.The media property-specific final buy data and posted data is readilyavailable in the database as described above in connection with FIG. 14.

Further, it is preferred that the stewardship analysis section bedisplayed in terms of dollars. The dollar value for the total plan costis available in the database as taught in connection with FIG. 12 (seefield 1234 of FIG. 12). The dollar values for the original buys incolumn 2142, for the affidavit amounts in column 2146, and for theremitted amounts in column 2150 are available in the database as taughtin connection with FIG. 13. The dollar values for the final buy column2144 and posted buy column 2146 are preferably computed using thecumulative cost values in the final buy data and the posted buy dataunder the applicable client/agency/media property/DMA/timeduration/demographic conditions.

Further, row 2154 preferably displays a percentage relating the totalvalues for the original buy cost, the final buy cost, the affidavitcost, and the posted buy cost to the plan cost. Thereafter, row 2156preferably displays the cost per TRP for each of the plan cost, theoriginal buy cost, the final buy cost, and the posted buy cost. Thisvalue is preferably computed as 100 times the total cost in row 2154divided by the total TRPs in row 2132 for the applicable category.Further still, it is preferred that row 2158 display a percentage thatrelates the cost per TRP for the original buy, the final buy, the postedbuy to the cost per TRP for the plan. This value is computed as 100times the appropriate cost per TRP in columns 2142, 2144, and 2148divided by the planned cost per TRP.

FIG. 21( b) illustrates an exemplary market analysis report 2160 thatcorresponds to box 2006 of FIG. 20( a). The report identifies theclient, advertising agency, target demographic, and time duration infields 2164, 2166, 2168, and 2170 respectively to which the report ispertinent. This data corresponds to the selections made by the auditorthrough the user interface 2000. Report 2160 details the agency'sperformance per DMA. Each row 2162 corresponds to a DMA associated withthe plan data for the specified conditions. Columns 2172, 2174, 2176,and 2178 identify the total number of TRPs for that row's DMA,respectively, in the plan, the original buy, the final buy, and theposted buy. These total values can be obtained as described above inconnection with row 2130 of FIG. 21( a).

Column 2180 preferably displays, for each DMA, an index comparing theamount of TRPs in the original buy with the amount of TRPs in the plan.This index is preferably displayed as a percentage and can be computedas 100 times the number of TRPs for that DMA in the original buy dividedby the number of TRPs for that DMA in the plan.

Column 2182 preferably displays, for each DMA, an index comparing theamount of TRPs in the final buy with the amount of TRPs in the plan.This index is preferably displayed as a percentage and can be computedas 100 times the number of TRPs for that DMA in the final buy divided bythe number of TRPs for that DMA in the plan.

Column 2184 preferably displays, for each DMA, an index comparing theamount of TRPs in the posted buy with the amount of TRPs in the plan.This index is preferably displayed as a percentage and can be computedas 100 times the number of TRPs for that DMA in the posted buy dividedby the number of TRPs for that DMA in the plan.

Lastly, column 2186 preferably displays, for each DMA, an indexcomparing the amount of TRPs in the posted buy with the amount of TRPsin the final buy. This index is preferably displayed as a percentage andcan be computed as 100 times the number of TRPs for that DMA in theposted buy divided by the number of TRPs for that DMA in the final buy.

FIG. 21( c) illustrates an exemplary market analysis report 2190 thatcorresponds to box 2008 of FIG. 20( a). This report identifies variousperformance indices in percentage terms for multiple advertisingagencies on behalf of a single client in multiple DMAs. The client forwhich the report 2190 was specified via field 2012 in FIG. 20( a) isidentified in field 2191. The demographic group to which the report isapplicable is preferably identified in field 2192.

The time period for which the report was specified via field 2014 ofFIG. 20( a) is identified in field 2193. Each row of the reportidentifies index data for a different DMA/agency pair. The DMA isidentified in column 2194 and the advertising agency is identified incolumn 2195. Columns 2196, 2197, and 2198 identify, for the DMA/agencypairs of columns 2194 and 2195, the percentage measure, relative to theplanned number of TRPs, of the original buy TRPs, final buy TRPs, andposted buy TRPs, respectively. Column 2199 identifies the percentagemeasure of the TRPs in the posted buy versus the TRPs in the final buyfor the DMA/agency pairs of columns 2194 and 2195. The data in thesecolumns can be calculated as discussed in connection with the likecolumns in the report of FIG. 21( a).

FIG. 21( d) illustrates an exemplary market analysis report 2101 thatcorresponds to box 2010 of FIG. 20( a). This report identifies variousperformance indices in total TRP terms for multiple advertising agencieson behalf of a single client in multiple DMAs. The client for which thereport 2101 was specified via field 2012 in FIG. 20( a) is identified infield 2103. The demographic group to which the report is applicable ispreferably identified in field 2105. The time period for which thereport was specified via field 2014 of FIG. 20( a) is identified infield 2107. Each row of the report identifies total TRP data for adifferent DMA/agency pair. The DMA is identified in column 2109 and theadvertising agency is identified in column 2111. Columns 2113, 2115,2117, and 2119 identify the total TRPs in the plan, original buy, finalbuy, and posted buy, respectively, for the DMA/agency pairs of columns2109 and 2111.

FIG. 20( b) illustrates a preferred user interface 2020 for generatingaverage ratings audit reports. Through selection of folder tab 2022, theauditor can control the creation of average ratings audit reports.Control conditions for the audit report are set through fields 2026 (forclient), and 2028 (for time duration). Preferably, field 2030 (foradvertising agency) is left unused because the report produced frominterface 2020 is preferably agency independent. As with interface 2000of FIG. 20( a), interface 2020 may also include field(s) (not shown) forspecifying a DMA and/or a demographic group to which the report will beapplicable. Checkbox 2024 corresponds to a selection of a “DaypartAverage Ratings Analysis” audit report. The user can create such anaudit report by selecting the “generate report” button 2032.

FIG. 22 illustrates an exemplary “Daypart Average Ratings Analysis”audit report 2200. The report preferably identifies the parameters forclient, DMA, demographic, and time duration in fields 2202, 2204, 2206,and 2208, respectively. Table 2210 includes TRP data broken down bydaypart (column 2218 a through column 2218 h) for the final buy TRPestimates, the posted TRP values received from a first independentsource, and TRP values received from a second independent source. Thesecond independent source TRP data is preferably NSI average ratingdata, which is well-known in the art. Each entry in row 2212 correspondsto an average estimated TRP value for the final buy entries per daypart.Each entry in row 2214 corresponds to the average posted ratings fromthe independent source for the actual advertisements in the posted buydata per daypart. Each entry in row 2216 corresponds to the NSI averagerating value per daypart. From this data, the indexes of rows 2220 and2222 are computed. Row 2220 displays, per daypart, a percentage relatingthe final ratings estimates of row 2212 to the NSI average ratings ofcolumn 2216 (for each daypart, 100 times the final ratings estimatedivided by the NSI average rating). Row 2222 displays, per daypart, apercentage relating the posted ratings of row 2214 to the NSI averageratings of column 2216 (for each daypart, 100 times the posted ratingsestimate divided by the NSI average rating). This audit report providesan accuracy measure for the agency's exposure estimates and furtherprovides an accuracy measure for the independent exposure data used toanalyze the posted buy data.

FIG. 20( c) illustrates a preferred user interface 2040 for generatingaudit reports detailing the cost per TRP. Through selection of foldertab 2042, the auditor can control the creation of these audit reports.Control conditions for the audit report are set through fields 2044 (forclient), 2046 (for time duration), field 2048 (for advertising agency),and field 2050 (for average/low/high (ALH) cost per TRP levels withinthe SQAD data). Also, it should be noted that the interface 2040 mayalso include field(s) (not shown) for specifying a DMA and/ordemographic group to which the report will be applicable. Checkbox 2052corresponds to a selection of a “Daypart CPP Analysis” audit report,wherein CPP stands for cost per point (or cost per TRP). Checkbox 2054corresponds to a selection of a “Daypart CPP Analysis (DMA Recap)” auditreport. Checkbox 2056 corresponds to a selection of a “Daypart CPPAnalysis (Multi AOR DMA Recap)” audit report. Lastly, checkbox 2058corresponds to a selection of a “Daypart CPP Analysis International”audit report. The user can create the selected ones of these auditreports by selecting the “generate report” button 2059.

FIG. 23( a) illustrates an exemplary “Daypart CPP Analysis” audit report2300. The control conditions for the report are displayed in field 2302(which identifies the client), in field 2304 (which identifies theapplicable DMA), in field 2306 (which identifies the applicabledemographic), in field 2308 (which identifies the applicable timeduration), and in field 2310 (which identifies the agency beingaudited). Further, field 2312 identifies the length of the actualadvertisements that are the subject of the report, and field 2314identifies the factor for the length, wherein the factor is a weightingscalar for the length that relates the length of an advertisement to itscost. Typically, a 15 second advertisement will have a factor of 0.7 fora 30 second length advertisement, and a 10 second advertisement willhave a factor of 0.5 for a 30 second length advertisement. If the report2300 is to include this length and factor data, it is preferred thatinterface 2040 of FIG. 20( c) include fields (not shown) through whichthe auditor can specify the length and factor.

Table 2315 includes rows corresponding to a cost for a TRP per daypart.Rows 2316 and 2318 correspond to the cost for a TRP in the final buydata per daypart and the cost for a TRP in the posted buy data perdaypart, respectively, under the applicable client/agency/DMAconditions. The costs for a TRP in the final buy per daypart arecomputed by dividing the cumulative final buy costs for all of the finalbuy spots in a particular daypart by the cumulative TRPs for all of thefinal buy spots in that particular daypart. The costs for a TRP in theposted buy per daypart are computed by dividing the cumulative postedbuy costs for all of the actual advertisements in a particular daypartby the cumulative TRPs for all of the actual advertisements in thatparticular daypart.

Row 2320 identifies the SQAD cost for a TRP per daypart. This SQAD datais known in the art and represents a commercially accepted averageindustry cost for a TRP point under the stated conditions of daypart,DMA, demographic, length, factor, and time duration. The entries in row2324 provide an index relating the final buy cost per TRP for eachdaypart to the corresponding SQAD value. Lastly, the entries in row 2326provide an index relating the posted buy cost per TRP for each daypartto the corresponding SQAD value. Thus, FIG. 23( a) provides anindication of whether the advertising agency has purchased media in anefficient manner relative to a relevant industry benchmark (such asSQAD).

The “Daypart CPP Analysis International” audit report (not shown) thatcorresponds to box 2058 of FIG. 20( c) is an international version ofaudit report 2300 of FIG. 23( a), albeit with some country-specificlanguage changes. For example, if the Daypart CPP Analysis Internationalreport is for Canadian markets, the term TRP would be expressed as TVR,the term DMA would be expressed as EMA, and the term CPP would beexpressed as CPR. Other than these nomenclature changes, the content ofthe report and its mode of generation remains the same.

FIG. 23( b) illustrates an exemplary “Daypart CPP Analysis (DMA Recap)”audit report 2330. Fields 2332 through 2342 correspond to the likefields in FIG. 23( a). Each row 2344 a and 2344 b corresponds to adifferent DMA that is the subject of the report. Column 2346 provides anindex to the average/low/high SQAD value for each DMA, as specified inthe ALH field 2050 of FIG. 20( c). Columns 2348 a through 2348 h providepercentages for each DMA by daypart that are indicative of the cost forone posted buy TRP versus the SQAD value for such a TRP. The values inrows 2344 a and 2344 b are computed in the same manner as those valuesin row 2326 of FIG. 23( a) for the applicable DMAs. The values in row2350 are computed as the average of the percentages for each DMA incolumns 2348 a through 2348 h, wherein inactive dayparts (dayparts forwhich no spots were purchased or ran) are not factored into the average.

FIG. 23( c) illustrates an exemplary “Multi AOR DMA Recap” audit report2360 corresponding to box 2056 of FIG. 20( c). This audit report 2360preferably displays the same content as that of audit report 2330 ofFIG. 23( b), albeit for a plurality of different agencies 2362 a, 2362b, . . . employed by the client.

FIG. 20( d) illustrates a preferred user interface 2060 for generatingaudit reports detailing under delivery (UD). Through selection of foldertab 2061, the auditor can control the creation of these audit reports.Control conditions for the audit report are set through fields 2062 (forclient), 2063 (for start time), field 2064 (for end time), and field2065 (for advertising agency). It should be noted that interface 2060may also include field(s) (not shown) for specifying a demographic groupand/or DMA applicable to the report. Because UD reports are most usefulwhen they track multiple quarters (so the restitution owed for UD from aprior quarter can be tracked), it is preferred that multiple quarters bespecified in the start and end time fields. However, if a singlequarter's UD report is desired, a user can generate such a report byspecifying the same time as the start time and the end time. Checkbox2066 corresponds to a selection of a “Detailed UD Report (Intl)” auditreport. Checkbox 2067 corresponds to a selection of a “Multi DMA UDReport” audit report. Checkbox 2068 corresponds to a selection of a“Multi AOR UD Report” audit report. Lastly, checkbox 2069 corresponds toa selection of a “Multi DMA AOR UD Report” audit report. The user cancreate the selected ones of these audit reports by selecting the“generate report” button 2070.

FIG. 24( a) illustrates an exemplary “Detailed UD Report” audit report2400 corresponding to box 2066 of FIG. 20( d). An under delivery (UD)situation occurs when a media property fails to deliver in a given timeperiod (preferably a quarter), through TRPs in the posted buy, at leasta minimum threshold of the TRPs requested in the final buy. This minimumthreshold is preferably 90%. The applicable control conditions forreport 2400 are specified in fields 2402, 2404, 2406, and 2408, whichidentify client, demographic group, time duration, and advertisingagency, respectively. Field 2410 identifies the date on which report2400 was generated. Field 2412 identifies the DMA for which the reportis pertinent. Row 2430 identifies the summed UD data for the mediaproperties in DMA 2412. Each row 2414 a, 2414 b, . . . corresponds to adifferent media property within DMA 2412. Column 2416 identifies thetotal number of estimated TRPs for a media property in the final buydata. Column 2418 identifies the total number of posted TRPs for a mediaproperty in the posted buy data. Column 2420 is an index measure thatidentifies the posted-to-final percentage (100 times the column 2418value divided by the column 2416 value). Column 2422 identifies thenumber of TRPs owed by a station, as determined per quarter, for underdelivery. This value may be calculated on a media property specificbasis for each quarter as: TRPs owed (by a media property) equals 0.9multiplied by the number of TRPs in the final buy with that mediaproperty minus the number of TRPs in the posted buy with that mediaproperty. Thus, for a multi-quarter report such as report 2400, the TRPsowed by each media property would be the sum of TRPs owed for eachquarter (quarters 1Q04 through 4Q04 in the example of FIG. 24( a)).

Column 2424 identifies the number of restitution TRPs that were postedfor the applicable media property during the specified time period 2406to make good on previously-owed UD TRPs. It is preferred that actualadvertisements that ran as UD restitution be flagged accordingly in theactual buy data, thereby rendering their detection in the database mucheasier. Column 2426 identifies a revised index that takes intoconsideration the restitution TRPs of column 2424 (revisedindex=100*(column 2424 value+column 2418 value)/column 2416 value).Column 2428 identifies the balance of UD TRPs, which is preferablycalculated, per quarter, as the difference between TRPs owed andrestitution TRPs. Thus, for a multi-quarter report such as report 2400,the balances reflected in column 2428 reflects the sum of thesequarterly differences between the TRPs owed and restitution TRPs.

Lastly, table 2432 identifies the UD data in monetary terms for allmedia properties in the DMA 2412. The monetary amount for value owed2434 can be computed as the sum of TRPs owed (column 2422, row 2430)multiplied by the agency-purchased cost per TRP ascertained from theposted buy data. Value received 2436 can be computed as the sum ofrestitution TRPs (column 2424, row 2430) multiplied by theagency-purchased cost per TRP. Balance 2438 can be computed as the sumof balances in column 2428 multiplied by the agency-purchased cost perTRP ascertained from the posted buy data.

FIG. 24( b) illustrates an exemplary “Multi DMA UD Report” audit report2440 corresponding to box 2067 of FIG. 20( d). This report provides UDdata for multiple DMAs 2442 a, 2442 b, . . . under control conditions2444. Column 2446 identifies the gross dollar amount spent in the postedbuy data for the DMA. Columns 2448, 2450, 2452, 2454, 2456, and 2458correspond to columns 2416, 2418, 2420, 2422, 2424, and 2426respectively of FIG. 24( a), but for an entire DMA (row 2430 of FIG. 24(a)).

FIG. 24( c) illustrates an exemplary “Multi AOR UD Report” audit report2460 corresponding to box 2068 of FIG. 20( d). This report provides UDdata for multiple agencies. The control conditions for the report areidentified in field 2462 (client-specific and time duration-specific).Each row 2464 a, 2464 b, . . . corresponds to a different agencyemployed by the client. The data in the columns corresponds to thenumber of DMAs in which the agency placed buys, the posted deliveryindex, TRPs owed, restitution TRPs owed, value owed, value received, andbalance for each agency. These values may be computed as would beunderstood by a person of ordinary skill in the art in view of FIGS. 24(a) and (b) and the descriptions thereof.

FIG. 24( d) illustrates an exemplary “Multi DMA/AOR UD Report” auditreport 2480 corresponding to box 2069 of FIG. 20( d). This reportdisplays the content of UD report 2440 of FIG. 24( b), but for multipleagencies 2482, 2482 b, . . .

FIG. 20( e) illustrates a preferred user interface 2075 for generatingvarious miscellaneous audit reports. Through selection of folder tab2076, the auditor can control the creation of these audit reports.Through fields 2077, 2078, and 2079, the auditor can specify,respectively, the client, quarter, and advertising agency on which theaudit report will be based.

Checkbox 2080 corresponds to an audit report that identifies whether anyof the advertisement postings in the posted buy data aired during aprogram for which the client has requested no advertising. In somecircumstances, a client will communicate to an agency that it does notwant its advertisements to run during certain programs. If the postedbuy data indicates that an actual advertisement did in fact run duringsuch a prohibited program, then the preferred embodiment of the parentinvention preferably detects such an occurrence. Preferably, a userinterface is provided to the auditor so that such program restrictionscan be entered in the database with the other plan data. FIG. 25( a)depicts a preferred Restricted Programming Report 2500. Report 2500details the restricted program(s) in column 2502 and the DMA therefor incolumn 2504, and further provides data about the unauthorizedadvertisement, this data preferably including its invoiced cost and TRPsachieved.

Checkbox 2081 corresponds to an audit report that identifies unspecifieddollars spent with each media property in the final buy data and or theposted buy data. As shown in FIG. 25(b), this audit report 2510 providesadvertisement spot level detail per media property of those spotsinvoiced by the media property that do not match any spots that wereplaced by the agency with that media property, as reflected in the finalbuy data.

Checkbox 2082 corresponds to an audit report that identifies bonusadvertisements by daypart, that is actual advertisements for which nocharge was made by the media property. As shown in FIG. 25( c), such areport 2520 preferably identifies, per DMA, the dayparts in which thebonus spots ran, the posted ratings for the bonus spots in the dayparts,and the number of bonus spots that ran in each daypart.

Checkbox 2083 corresponds to an audit report that identifies daypartaudience delivery/TRPs, which helps clients understand when and wherethey are receiving billboards. As shown in FIG. 25( d), this auditreport 2530 preferably identifies, per DMA, the dayparts in which thebillboards ran, the posted ratings therefor, and the number of billboardspots per daypart. It is preferred that the daypart codes assigned tothe actual advertisements include a code for billboards (such as “BB”code).

Checkbox 2084 corresponds to an audit report that identifies marketanalysis data for a user-specified ISCI code. As shown in FIG. 25( e),report 2540 preferably identifies, per DMA, how many spots ran for eachISCI code, and the percentage total that each ISCI code took up amongall the spots that ran in that DMA.

Checkbox 2085 corresponds to an audit report that identifies DMA datafor a user-specified ISCI code. As shown in FIG. 25( f), this report2550 preferably provides the details of report 2540 of FIG. 25( e) on aDMA level rather than on a per media property level.

Checkbox 2087 corresponds to an audit report that identifies whether anyof the TRP estimates for the advertisement requests in the final buydata fall below a minimum threshold value. Some clients will requestthat no advertisements be requested for a time slot expected to generatea TRP below a minimum threshold level. Preferably, if such a situationexists, the user interface for entering plan data includes a field forentering the minimum threshold value for the final buy data. As shown inFIG. 25( g), this report 2560 preferably identifies, per DMA, pertinentdata about these spots. The violation cost preferably identifies thecost for the actual advertisement that should not have been purchasedpursuant to the minimum ratings threshold. The daypart cost columnidentifies the total costs for the actual advertisements placed by theagency in a DMA for each daypart. The index corresponding thereto is apercentage measure of the violation cost to the daypart cost, whichthereby indicates how much of a daypart's cost was taken up withadvertising that should not have been purchased. The remaining columnsof this audit report 2360 preferably display this data in TRP terms.

Checkbox 2088 corresponds to an audit report that identifies whether anyof the TRPs posted for the actual advertisements in the posted buy datafall below a minimum threshold value. This audit report (not shown) issimilar in type to that of FIG. 25( g), but uses the posted buy data foranalysis. As mentioned above in connection with the final buy, someclients will request that no advertisements be aired during a time slotthat will generate a TRP below a minimum threshold level. Preferably, ifsuch a situation exists, the user interface for entering plan dataincludes a field for entering the minimum threshold value for the postedbuy data.

Checkbox 2089 corresponds to an audit report that identifies whether anappropriate degree of spacing (separation) between advertisements forthe plan was achieved. Some clients desire that there be some minimumlevel of spacing between the client's advertisements. The posted buydata includes air time data that allows a separation determination to bemade. Preferably, if such a minimum separation rule exists, the userinterface for entering plan data includes a field for entering theparameters of the separation rule. As shown in FIG. 25( h), this report2570 preferably identifies a separation rule 2572, such as a rule thatthe time separation between successive actual advertisements in a DMA be20 minutes. The remainder of the report 2570 preferably identifies, perDMA, the successive actual advertisements 2574 and 2576, pertinentdetails therefor (such as the run time), and the actual separation 2578between the spots. The detail of report 2570 is preferably limited tosuccessive spots that violate the rule.

It is also worth noting that the audit reports generated by thepreferred embodiment may also include summary paragraphs that describesalient aspects of the audit. For example, the report may includedescriptive paragraphs that communicate to the client the amount of UDrestitution owed to them, or the report may include descriptiveparagraphs that communicate to the client the posted buy-to-plan indexof total TRP values, or the report may include descriptive paragraphsthat communicate to the client how the agency's cost per TRP measuredagainst industry averages. A sample preferred audit report for TV/radiois included herein as FIGS. 26-68 (see also Appendix A of theincorporated parent '466 patent application).

While the parent invention has been described above in relation to itspreferred embodiment, various modifications may be made thereto thatstill fall within the invention's scope, as would be recognized by thoseof ordinary skill in the art. For example, the techniques of thepreferred embodiment can also be applied to advertising in print media.Corollaries to the original buy and the final buy for TV/radio ads arethe original insertion orders and the revised insertion orders for printads. Print advertising plans typically specify cost, circulation, andpositioning. Exposure data for print media is typically measured interms of circulation, and a suitable third party source for suchcirculation data is the Audit Bureau of Circulation (ABC), as is knownin the art. A sample preferred audit report for print media is includedherein as FIGS. 69-278 (see also Appendix B of the incorporated parent'466 patent application). Such modifications to the invention will berecognizable upon review of the teachings herein. Accordingly, the fullscope of the parent invention is to be defined solely by the appendedclaims and their legal equivalents.

Present U.S. patent application Ser. No. 11/253,040

FIG. 1 depicts an overview of the preferred embodiment of the presentinvention. The system 100 comprises at least one media property 102, atleast one advertising agency 104, an accounts payable (NP) computersystem 108, and an invoice reconciliation system 110.

A computer system operated by the media property 102 preferably sendsinvoice data to the invoice reconciliation system 110. This invoice datacorresponds to an invoice for advertisement spots that were run by thatmedia property 102 for an advertising agency 104 on behalf of itsclient. These invoices are typically sent 15-20 days after the end ofthe standard broadcast month. However, with the present invention, thisneed not be the case, as invoices can just as easily be sent on aweekly, daily, bimonthly or other basis. This invoice data is preferablycommunicated by the media property 102 to the invoice reconciliationsystem 110 electronically over a network such as the Internet. Preferredtransmission techniques include e-mail, publication on an electronicbulletin board, and file uploads over a network, such as http uploadingover the Internet. However, any known form of communication can be usedto communicate the invoice data to the invoice reconciliation system110, including leased data lines and paper copy mailings from the mediaproperty 102 to an operator of the invoice reconciliation system 110.However, the transmission of invoice data to the operator of the invoicereconciliation system 110 in the form of paper copies is not preferred(at least in connection with the practice of the preferred embodiment ofthe present invention) as it requires intervention by data entrypersonnel to get the invoice data into a database.

A computer system operated by the advertising agency 104 preferablysends raw final buy data to the invoice reconciliation system 110. Thisraw final buy data corresponds to final requests placed by the agency104 on behalf of its client for advertisement spots to be run by a mediaproperty 102. This raw final buy data is preferably communicated by themedia property 102 to the invoice reconciliation system 110electronically over a network such as the Internet. However, any knownform of communication can be used to communicate the raw final buy datato the invoice reconciliation system 110, including leased data linesand paper copy mailings from the advertising agency 102 to an operatorof the invoice reconciliation system 110. However, the transmission ofraw final buy data to the operator of the invoice reconciliation system110 in the form of paper copies is not preferred as it requiresintervention by data entry personnel to get the invoice data into adatabase. It is believed that through various negotiations betweenagencies, agency clients, and operator(s) of the invoice reconciliationsystem, advertising agencies can be persuaded to utilize electronictransmission of the raw final buy data to the invoice reconciliationsystem. Preferred transmission techniques include e-mail, publication onan electronic bulletin board, and file uploads over a network, such ashttp uploading over the Internet.

The agency 104 typically prebills the client for the original buy, withbilling adjustments being issued to the client as changes occur with theoriginal buy. As such, the resultant pre-billing to the client typicallyapproximates final buy billing. Thus, before the agency has beeninvoiced for the ad spots requested in the final buy, the client haspaid the agency 104 some amount of funds that are to be applied towardinvoices from media properties. The agency 104 typically deposits thispayment amount in an account, wherein appropriate amounts of thedeposited funds are later transferred from the account to theappropriate media property after reconciling an invoice from that mediaproperty. This account is typically an interest bearing account with theadvertising agency 104 as the account holder, and the agency 104typically collects the interest that accrues to the funds placed in theaccount. As such, the longer time that it takes the agency to reconcilemedia property invoices, the more interest money that the agency takesin.

The inventors herein believe that media properties and advertisers(clients) are desirous of significantly reducing the account receivabletime period because prompter payment on invoices will allow the mediaproperties to take advantage of the “time value of money”. Accordingly,the inventors herein further believe that strong market potential existsin the advertising industry for a system by which media propertyinvoices can be more promptly reconciled. In turn, media properties canbe expected to provide discounts to advertisers in exchange for promptpayment on invoices (e.g., a 2% discount for paying an invoice within 10days). Toward this end, the invoice reconciliation system 110 isprovided.

The primary task of the invoice reconciliation system is to reconcileinvoices from media properties with final buys from advertising agenciesto ensure that agencies (and their clients) are being properly billedfor what they purchased. This reconciliation can be done in an automatedfashion by computer software wherein matches between invoices and finalbuys (preferably on a per ad spot basis) are identified automatically.Invoice items that cannot be matched to a corresponding final buy itemare preferably referred to an exception handling process within theinvoice reconciliation system 110, wherein GUIs are preferably providedto seek human intervention to resolve invoice-to-final buyinconsistencies.

After reconciling the invoice data with the final buy data, the invoicereconciliation system 110 can preferably provide payment authorizationinstructions regarding reconciled invoices to the NP system 108 thatenable the transfer of an amount of funds to the media property 102 thatis consistent with invoiced items that were satisfactorily reconciled(via either the automatic matching process or the exception handlingprocess) with the final buy items. These instructions are preferablyprovided directly to an automated financial system 108 that controls theaccount such that funds can be transferred electronically from theaccount to the media property 102.

FIG. 2 provides a block diagram overview of a preferred invoicereconciliation system 110, which preferably comprises a computer 200 anda database 202 in communication with the computer 200.

The computer 200 is preferably a commercially-available Dell Poweredge2650 or a device of similar processing capabilities, and the database202 is preferably a commercially-available Microsoft MS SQL 2000 or anewer version thereof. It should be understood that the computer 200 anddatabase 202 can be implemented with other hardware, including animplementation as a personal computer, workstation, or server that canbe accessed over a network such as the Internet. As will be explained ingreater detail below, the database 202 serves as a repository for thedata used in the invoice reconciliation process. The computer 200preferably provides the programming logic, or code segments executableby a processor, for (1) converting the received raw final buy data intoa common format for storage in the database 202 (conversion and storagesoftware 204), (2) performing the invoice reconciliation, including thecommunication of payment instructions (reconciliation software 206), and(3) displaying and controlling a plurality of GUIs that are configuredto interact with a user to manage the invoice reconciliation and paymentprocess and, if necessary, provide data entry functionality (userinterface software 208). This programming logic can reside on memorythat is accessible to computer 200 or on a device such as a compact disc(CD) or the like to be accessed by computer 200 from a disk drive or thelike.

Preferred tasks for the GUIs are to provide the user with the ability toperform exception handling tasks that arise during the invoicereconciliation process and to control the payment process. To operatethe invoice reconciliation system, these GUIs can preferably be accessedby a user from a remote computer in communication with computer 200 overa network such as the Internet. However, this need not be the case. Theusers for system 110 can include employees of the client, advertisingagency, or media property, or hired outside parties, as explained belowin connection with FIGS. 8( a)-10(b). Conventional security techniquesare preferably implemented on computer 200 to prevent users from gainingaccess to unauthorized data. For example, client users will preferablyonly be able to access their own final buy and invoice data, advertisingagency users will preferably only be able to access final buy data andinvoice data relating to advertising spots they have placed, and mediaproperty users will preferably only be able to access their own invoicedata and the final buy data related to their invoices. Outside partyusers' access to data will be limited in accordance with the authorityof the party (client, advertising agency or media property) that hiredthem.

Creating the Database of Converted Invoice and Final Buy Data:

One aspect of the preferred embodiment relates to storing invoice dataand final buy data in the database 202. Preferably, the final buy datais stored in a common format to facilitate the reconciliation process ofmatching final buy items with invoice items. It is expected that the rawfinal buy data received from different advertising agencies will possessvarying formats. In such cases, it is preferred that, prior to beingstored in database 202, this raw final buy data be converted to a commonformat. However, as a less preferred alternative, the raw final buy datacan be stored in the database 202 in its raw format, and the conversioncan occur at the time of the matching process upon retrieval from thedatabase. Another less preferred alternative is for the reconciliationlogic to take on the burden of accounting for the different expected rawfinal buy data formats, with no final buy data conversion taking place.Further still, it is worth noting that the conversion step may berendered unnecessary if the data formats for the media property'sinvoice data and advertising agency's raw final buy data are both thesame or if the raw final buy formats for the different agencies are allthe same. Such situations can conceivably exist if the media propertiesand advertising agencies use software on their respective computersystems that is configured to output the invoice data and final buy datain formats that allow for an apples to apples comparison without theneed of a conversion step. However, at the current time, the inventorsbelieve that it is highly likely that a conversion step will be neededto ensure a wide scope of potential use for the preferred embodiment ofthe present invention. The invoice data will preferably arrive in an XMLformat, from which the pertinent data can be readily extracted andstored in database 202 (step 308 of FIG. 3).

As mentioned above, the raw final buy data can be expected to arrive ina variety of different formats depending upon the platform used by eachadvertising agency. The conversion of raw final buy data to a commonformat preferably utilizes the techniques disclosed in pending U.S.patent application Ser. No. 10/810,466, filed Mar. 26, 2004 describedabove and entitled “Method and Apparatus for Auditing the Performance ofAdvertising Agencies on Behalf of Their Clients”, the entire disclosureof which has been incorporated herein by reference. That pendingapplication discloses, among other things, a technique whereby final buydata and actual buy data are converted to a common format to enable anauditing process.

FIG. 3 is a flowchart overview for a preferred final buy data conversionprocess performed by computer 200. At step 300, the raw data relatingagencies' final buys are received (preferably electronically). Eachagency may store the final buy data in a different format depending uponthe software packages used by the agencies. Examples of industry-usedformats for the final buy data are the DDS format (300 a) for media buysoftware from Donovan Data Systems, Inc., the Strata format (300 b) formedia buy software from Strata Marketing, Inc., the Adware (300 c)format for software from AdWare Systems, Inc., and the SmartPlus format(300 d) for software from the company Marketing Resources Plus. Itshould be noted that other data formats may also be used in the practiceof the invention.

FIG. 4 illustrates a sample format for a raw final buy data file thatwould be received electronically from an advertising agency in thepreferred embodiment of the present invention. The final buy data can beprovided as a flat file, as a relational database structure, or otherknown forms for maintaining data. In the example of FIG. 4, the finalbuy data is presented as a flat file through table 400, with each tablerow corresponding to a different final buy item for an advertisementspot that was requested by the agency and each column includingpertinent data for that advertisement spot.

With reference to FIG. 4, data in column 402 identifies the media inwhich the advertisement spot is to run. The data in column 404identifies the client. The data in column 406 provides an identifier forthe product/service that corresponds to the advertisement. The data incolumn 408 provides an identifier code for the estimate corresponding tothe advertisement spot, and the data in column 410 provides the name ofthe estimate corresponding to the advertisement spot.

Further, the data in column 412 identifies the beginning and end datesfor the final buy request (expressed by week). The data in column 414identifies the DMA in which the final buy was requested, the data incolumn 416 identifies the media property with which the final buyrequest was placed, and the data in column 418 identifies a buy linecode for the media property. The buy line code serves as a reference tothe advertising agency buy line, as is known in the art.

Further still, the data in column 420 identifies the program duringwhich the advertisement spot is to run, the data in column 422identifies the daypart code for the time during which the advertisementspot is to air, the data in column 424 specifies the length (in seconds)for the advertisement spot, the data in column 426 specifies thescheduling rotation by day for the program, and the data in column 428identifies the air time for the program. Moreover, the data in column430 identifies the cost for the advertisement spot, and the data incolumn 432 identifies an estimation by the agency of the amount ofexposure for the advertisement spot (in terms of a total number of TRPsthat the agency thinks the advertisement spot will achieve if it runsduring a commercial break for the program). Columns 434, 436, and 438each correspond to a particular week during the time period identifiedin column 412. The data in each of these columns identifies the numberof advertisement spots requested for that program during the specifiedweek. Lastly, the data in column 440 includes any comments that anagency may wish to include for the advertisement spot. For example, theagency may want to note as a comment that the spot was aired to makegood on an earlier missed spot, that a spot's tardy airing was due to asports program running long, or that a spot's airing was pre-empted bynews war coverage.

It should be noted that the final buy data format of FIG. 4 is exemplaryonly. Different advertising agencies will often use different formats.As a result of this diversity, the final buy data received by apractitioner of the present invention is expected to have a wide varietyof formatting differences. For example, two agencies may use the samefields for their data, but provide those fields in a differentsequential order. Also, some of the fields used by one agency may not beused by another agency (e.g., one agency provides a field for “line”data (column 418 in FIG. 4, while another agency does not). Also, two ormore agencies may use different formats for the data that populates thefields (e.g., Agency A codes dates numerically as mm/dd/yy (12/31/03)while Agency B codes dates alphanumerically as month name, month date,year (Dec. 31, 2003); Agency A codes dayparts with a two letter code,Agency B codes dayparts with a three letter code, and Agency C codesdayparts with a four letter code). Further still, when the final buydata is provided as electronic files, some agencies may provide thefinal buy data in a relational database format, while others may supplythe data in a flat file format, while yet others may supply the data inother known electronic data structures.

Moreover, any fields that are not needed to perform invoicereconciliation, may optionally be omitted from the final buy datatransmitted from the agency 104, from the raw final buy data that isconverted to the common format, or from the converted final buy datathat is stored in database 202.

FIG. 5 illustrates a sample format for an invoice data file that wouldbe received electronically from a media property in the preferredembodiment of the present invention. As with the final buy data, theinvoice data can be provided as a flat file, as a relational databasestructure, or other known forms for maintaining data. In the example ofFIG. 5, the invoice data is presented as a flat file through table 500,with each table row corresponding to a different invoice item for anadvertisement spot that was run by a media property (an actualadvertisement) and each column including pertinent data for that actualadvertisement.

The data in column 502 identifies the client for whom the actualadvertisement ran, and the data in column 504 identifies the advertisingagency who placed that advertisement on the client's behalf. Columns 506and 508 identify, respectively, the name of the estimate correspondingto the advertisement spot, and a code for the estimate corresponding tothe advertisement spot. These fields effectively correspond to columns410 and 408 of FIG. 4. Column 510 identifies an invoice number that isapplicable to an actual advertisement. Columns 514, 516, and 518identify, respectively, the date on which the actual advertisement ran,the time at which the actual advertisement ran (typically identified bythe hour and minute that the actual advertisement began), and length forthe actual advertisement. Column 520 identifies the gross cost for theactual advertisement and column 522 identifies the ad-ID or ISCIcreative code for the actual advertisement, which is preferably definedby industry standards as known in the art.

It should be noted that, as with the final buy data, the invoice dataformat of FIG. 5 is exemplary only. It can be expected that most mediaproperties electronic invoices will be in an XML format, in which theinvoice data is tagged to facilitate the extraction of pertinent datatherefrom (step 308). Also, in the event of disparities in the fieldformatting within invoice files from different media properties, theinvoice data can also go through the conversion process of steps 300-306of FIG. 3. Such conversion can be implemented in response to userinteraction with a GUI-based export tool through which media propertiessubmit their invoice data to the invoice reconciliation system 110.Using ordinary skill in the art, software to perform this extractionand/or format conversion can be readily created.

Because of the diversity in the received raw final buy data, the presentinvention preferably converts this received final buy data to a commonformat to greatly simplify the processing logic used to reconcileinvoiced advertisements with advertisements requested in the final buy.Accordingly, the programming logic for performing the invoicereconciliation need not account for each individual raw final buy datafile format, thereby enhancing the modularity of the reconciliationlogic to provide for increased flexibility in the event thereconciliation logic is to be altered, or in the event that a new formatfor raw data is received.

A practitioner of the present invention can select the common format forthe conversion step 302 of FIG. 3 as a design choice based on a personalevaluation of the facts and circumstances relating to the system.Preferably, the common format that is chosen is the XML format used bythe media properties for the invoice data described in connection withFIG. 5. However, other common formats can be used. For example, thecommon format can also be one of the existing “raw” final buy dataformats (such as Strata or DDS). However, as facts and circumstances maydictate, some practitioners of the present invention may find it moreagreeable to develop their own common format. Further, the datastructures for the common format may also be selected to be structuresfor a relational database to facilitate storage using well-knowndatabase language techniques, or it can be a flat file format forpractitioners of the present invention who are less comfortable withrelational databases. In the event that the common format is a formatthat is different than the invoice data format, then it is preferredthat the conversion process described for the final buy data also beperformed on the invoice data.

Once the practitioner of the present invention identifies the raw finalbuy data formats and common data format involved in the conversionprocess, a mapping table for mapping raw data values for each of thefields in the raw final buy data file records in the various exemplaryfile formats 300 a through 300 d into the common format can be generatedusing ordinary skill in the art. This mapping table can then be used inperforming the conversion step 302.

The output of the conversion step 302 will be an import/export file 304for the converted final buy data. The data in this file 304 will be inthe common format. Thereafter, at step 306, this common format file 304is imported into a database to create a database 202 of invoice data andconverted final buy data. Preferably, the final buy data items arestored in the database 202 such that they are associated withappropriate identifiers for the advertising agencies that placed thefinal buys. Further still, the invoice items are preferably stored inthe database 202 such that they are associated with appropriateidentifiers for the media properties that ran the advertising spots.Database 202 can be implemented as a single database or can beimplemented as several distributed databases according to the preferenceof a practitioner of the invention.

Reconciling Converted Invoice Data with Converted Final Buy Data:

From the data stored in database 202, media property invoices can beaccurately and efficiently reconciled to determine appropriate paymentamounts and identify invoice items that are in dispute. FIG. 6illustrates a flowchart for a preferred reconciliation process that isexecuted by computer 200. It is worth noting that the computer 200 thatperforms the reconciliation process need not be the same computer thatperformed the conversion process of FIG. 3.

At step 600, the user selects the media property, client, andadvertising agency that will be applicable to the reconciliationprocess. The user may also enter an invoice number or other criteria toidentify the invoice against which the reconciliation process will run.These selections are preferably made by the user via one or more GUIs.If the user is the client, the client portion of this selection ispreferably pre-set to only that client (to thereby avoid a clientgaining access to the advertising data of another company). If the useris the advertising agency, (1) the advertising agency portion of thisselection is preferably pre-set to only that advertising agency (tothereby avoid an advertising agency gaining access to the advertisingdata of another advertising agency), and (2) the client portion of thisselection is configured to allow the advertising agency to select onlyclients that it represents (to thereby avoid an advertising agencygaining access to the advertising data of non-clients). Preferably, step600 is initiated after receipt of a media property invoice, which aretypically issued in accordance with the industry standard broadcastmonth.

Once the media property/client/advertising agency constraints have beenselected, the process preferably retrieves from database 202 the pendingextracted invoice items and pending converted final buy items that towhich the media property/client/advertising agency constraints areapplicable (step 602). An invoice item and final buy item can be said tobe “pending” if not yet reconciled. Because the final buy data will beavailable well before the invoice data corresponding thereto isavailable, it can generally be expected that the appropriate final buydata will be available for retrieval from the database when a mediaproperty invoice is received.

Next, at step 604, the process attempts to pair retrieved invoice itemswith retrieved final buy items to thereby identify (1) full matchesbetween invoice items and final buy items, (2) partial matches betweeninvoice items and final buy items, and (3) invoice items and/or finalbuy items that cannot be paired with a counterpart. FIG. 7 illustratesstep 604 in greater detail. At step 700, the retrieved final buy itemsare summed. At step 702, the retrieved invoice items are summed. At step704, these sums are compared. If the invoice items sum and final buyitems sum do not match, then this indicates that either one or moreextra invoice items are present or one or more extra final buy items arepresent (step 708). Too many invoice items indicates that one or more ofthe invoiced advertising spots were not purchased (a “run but notpurchased” exception handling condition). Too many final buy itemsindicates that one or of the requested advertising spots was not run (a“purchased but not run” exception handling condition). The value of thedifference between the sums represents the number of such exceptionhandling conditions that exist (step 710). If the sums are equal, thesystem will determine that no “run but not purchased” or “purchased butnot run” exception handling conditions exist (step 706). This does notnecessarily indicate that what was purchased was run and what was runwas purchased (as it may mean that an equal number of “run but notpurchased” and “purchased but not run” inconsistencies exist), but thesystem will detect these anomalies as a mismatched pair rather than anunmatched item. It is worth noting that techniques other than steps700-708 may be used in connection with step 604. For example, a varietyof matching metrics can be used to assess the degree of a match betweenan invoice item and a final buy item, wherein extremely low levels ofmatching (or complete mismatching) can result in “run but not purchased”and/or “purchased but not run” exception handling conditions beingfound.

At step 712, the retrieved final buy items and the retrieved invoiceitems are processed to find invoice item-to-final buy item pairs thatmatch in the following fields (1) estimate name fields 410 and 506, (2)estimate number/code fields 408 and 508, (3) times field 428 and spottime field 516, (4) length field 424 and spot length field 518, (5) costper spot field 430 and gross spot cost field 520, and (6) buy datesfield 412 and spot date 514. Invoice items that fully match final buyitems in each of these fields are preferably identified as full matches,and the process flags those items accordingly (step 714). Fully matchingitems represent items that have been satisfactorily reconciled such thatpayment is approved therefor. A running total that represents the amountof money approved for payment on an invoice is preferably maintained asfull matches are identified.

For invoice items and final buy items that do not fully match, step 716operates to identify the appropriate exception handling conditions forthe mismatches. To pair partially matching invoice items with final buyitems, a variety of techniques can be used. Preferably, each invoiceitem is paired with the final buy item that it most closely matches. Ifone or more “purchased but not run” exception handling conditions arefound to exist at step 710, the final buy item(s) with the leastsimilarity to any of the invoice items can be designated with the“purchased but not run” exception handling condition. If one or more“run but not purchased” exception handling conditions are found to existat step 710, the invoice item(s) with the least similarity to any of thefinal buy items can be designated with the “run but not purchased”exception handling condition. Additional examples of preferred exceptionhandling conditions include (1) a spot cost inconsistency exception forpairs whose cost fields do not match, (2) a spot length inconsistencyexception for pairs whose length fields do not match, (3) a spot timeinconsistency exception for pairs whose time fields cannot becorrelated, and (4) a spot date inconsistency exception for pairs whosedate fields cannot be correlated. For pairs that mismatch in more thanone field (e.g., a pair for which a spot cost inconsistency exceptionand a spot length inconsistency exception exists), more than oneexception handling condition may apply. Furthermore, it should beunderstood that more or fewer exception handling conditions can bedefined if desired by a practitioner of the present invention. Forexample, the Ad-ID/ISCI-related fields in the final buy and invoice datacan also be reconciled to determine whether the appropriateadvertisement was run, presuming appropriate final buy data is availableto perform such reconciliation.

Preferably, steps 712-716 incorporate a tolerance (e.g., +/−2 minutes)into the time range for the final buy item when assessing whether thespot time for the invoice data matches what was requested. Thistolerance may be defined by the user via a GUI. Through this tolerance,a time match can be found even if the media property ran theadvertisement in question outside of the final buy's time range, so longas the advertisement still ran sufficiently close to the time range tofall within the tolerance. It is worth noting that this tolerance neednot be user-specified; it can alternately be a predetermined built-infeature of the reconciliation system.

Returning to FIG. 6, at step 606, a determination is made as to whetherall of the invoice items on the subject invoice have been found to befully matching. If the answer is yes, then that invoice is approved forpayment, and at step 608, the process operates to upload paymentinstructions to the accounts payable (NP) computer system 108 thatenable the reconciled invoice to be paid. The amount of payment that isauthorized via these instructions can include any discounts that havebeen negotiated with the media property for prompt payment of itsinvoices. For example, a media property may agree to provide some formof discount (e.g., 2%) on an invoice if payment is made on that invoicewithin a predetermined amount of time (e.g., 48 hours). These paymentsinstructions will preferably interface with the NP software on computersystem 108 to provide the NP software with an identifier for theapplicable media property, an identifier for the applicable invoice, andthe net amount of payment due on the invoice. These instructions mayalso include an identifier or other related data for an applicablecampaign corresponding to the advertisements that are the subject of theinvoice. The exact details of these instructions are expected to vary asa function of what NP software package is run by computer system 108.Examples of common NP software include the various NP software packagesprovided by companies such as Oracle/PeopleSoft, Microsoft, and SAP.

If step 606 results in a determination that less than all of the invoiceitems included in the subject invoice have been successfully reconciled,then the process preferably proceeds to step 610, where exceptionhandling for the mismatched and unmatched items identified by step 716occurs. FIGS. 8( a)-(f) depict exemplary GUIs through which users canhandle the exceptions.

FIG. 8( a) depicts a preferred GUI 1000 for handling a “spot run but notpurchased” exception which occurs when an invoice item cannot be pairedwith a final buy item. GUI 1000 preferably includes a display section1002 that identifies the invoice item data for such a spot. This datapreferably includes an identification of the media property, client, andadvertising agency to which the invoice item is applicable. Further,this data preferably includes an identification of the estimate name,estimate number, invoice number, invoice date, spot date, spot time,spot length, spot cost, and ad-Id/ISCI/creative code. From this data andfrom any other guidelines that may be in place for processing suchexceptions (e.g., instructions from a client such as agency buyingguidelines as to how to handle such an exception), the user can chooseto undertake any of a plurality of options. A first option is to pay theinvoice item in full and update the buy line accordingly via button1004. Upon selection of button 1004, that final buy item-invoice itempair is marked as reconciled and the running total that represents theamount to be paid to the media property is preferably increased by thespot cost amount that is displayed in section 1002. Also, updating thebuy line following selection of button 1004 preferably results in theinvoiced spot being added to the agency's buy line and a billing updatebeing sent to the client. Another option is to reject payment on theinvoice and update the buy line accordingly via button 1006. In thisinstance, updating the buy line preferably results in the spot beingsubtracted from the invoice and a billing update message being sent tothe media property to inform the media property of the discrepancy. Thismessage can be communicated to the media property in a variety of ways.For example, an email could be sent to the media property. Preferably,in an embodiment wherein the users access computer 200 of system 110 viaa network such as the Internet, a message for a media property is placedin a mailbox associated with that media property, the messages in thismailbox being accessible via one or more GUIs as described in connectionwith FIGS. 10( a) and (b). Until the media property approves therejection, payment on all or a portion of the subject invoice(identified by the invoice number field displayed in FIG. 8( a) willpreferably be put on hold. A final option is to add a comment that is tobe associated with the invoice item via button 1008.

FIG. 8( b) depicts a preferred GUI 1020 for handling a “spot purchasedbut not run” exception which occurs when a final buy item cannot bepaired with an invoice item. GUI 1020 preferably includes a displaysection 1022 that identifies the final buy item data for such a spot.The final buy data fields that are displayed are preferably the same asthose shown in FIG. 4. This data preferably also includes anidentification of the media property, client, and advertising agency towhich the invoice item is applicable. From this data and from any otherguidelines that may be in place for processing such exceptions (e.g.,instructions from a client as to how to handle such an exception), theuser can choose to undertake any of a plurality of options. A firstoption is to pay the invoice amount in full, request a credit for thespot cost, and update the buy line accordingly, via button 1010. Uponselection of button 1010, (1) the running total that represents theamount to be paid to the media property is preferably increased by theinvoice item's spot cost amount that is displayed in section 1032, and(2) a credit from the media property in the amount of that spot cost isrequested. To communicate this credit request, a corresponding messageis preferably electronically sent to the media property. Preferably,until the media property approves the credit request, payment on all ora portion of the subject invoice is put on hold.

If desired by a practitioner of the present invention, separate commandscan be entered by the user to approve invoice payment and thereafterrequest a credit, for example by the inclusion of a separate “requestcredit” button on the GUI or by the inclusion of a second GUI throughwhich the user can request a credit. Also, updating the buy linefollowing selection of button 1010 preferably results in the invoicedspot being added to the agency's buy line and a billing update beingsent to the client. Additional options that the user can choose arepreferably those set forth in connection with buttons 1006 and 1008described above.

FIG. 8( c) depicts a preferred GUI 1030 for handling a “spot costinconsistency” exception which occurs when a final buy item's “cost perspot” data does not match the “spot cost” data in its counterpartinvoice item. GUI 1030 preferably includes a display section 1032 thatidentifies the media property, client, and advertising agency to whichthe spot cost inconsistency is applicable. Section 1032 preferably alsolists the pertinent data fields for the applicable final buy item andapplicable invoice item (preferably the fields shown in FIGS. 4 and 5).Display section 1034 preferably identifies the difference in costbetween the final buy item's “cost per spot” field and the invoiceitem's “spot cost” field. If the invoice item's cost is greater than thefinal buy item's cost, then this difference in section 1034 ispreferably a positive number. If the final buy item's cost is greaterthan the invoice item's cost, then this difference in section 1034 ispreferably a negative number. In situations where the invoice item costis greater than the final buy item cost (or vice versa), from the datain sections 1032 and 1034 and from any other guidelines that may be inplace for processing such exceptions (e.g., instructions from a clientas to how to handle such an exception), the user can choose to undertakeany of a plurality of options. A first option is to pay the invoiceamount in full, request a credit for the difference in section 1034, andupdate the buy line accordingly, via button 1010. A second option is topay the final buy amount and update the buy line accordingly, via button1038. With this option, a message is preferably electronically sent tothe media property requesting that the invoiced amount for the item beadjusted to the final buy amount. Until the media property consents tothe requested change, payment on all or a portion of the subject invoiceis preferably put on hold. Yet other options include rejecting paymentvia button 1006 and adding a comment via button 1008, as set forth inconnection with FIGS. 8( a) and (b).

FIG. 8( d) depicts a preferred GUI 1040 for handling a “spot lengthinconsistency” exception which occurs when a final buy item's “length”data does not match the “spot length” data in its counterpart invoiceitem. GUI 1040 preferably includes a display section 1032 thatidentifies the media property, client, and advertising agency to whichthe spot length inconsistency is applicable. Section 1032 preferablyalso lists the pertinent data fields for the applicable final buy itemand applicable invoice item (preferably the fields shown in FIGS. 4 and5). Display section 1042 preferably identifies the difference in costbetween the final buy item's “length” field and the invoice item's “spotlength” field. If the invoice item's length is less than the final buyitem's length, then this difference in section 1042 is preferably anegative number. If the final buy item's length is less than the invoiceitem's length, then this difference in section 1042 is preferably apositive number. In situations where the final buy item length isgreater than the invoice item length (or vice versa), from the data insections 1032 and 1042 and from any other guidelines that may be inplace for processing such exceptions (e.g., instructions from a clientas to how to handle such an exception), the user can choose to undertakeany of a plurality of options, which preferably include the options setforth above in connection with buttons 1010, 1006, and 1008.

FIG. 8( e) depicts a preferred GUI 1050 for handling a “spot timeinconsistency” exception which occurs when the invoice item's “spottime” data does not fall within the range of its counterpart final buyitem's “times” data range (including any tolerance that may be builtinto this range as previously explained). GUI 1050 preferably includes adisplay section 1032 that identifies the media property, client, andadvertising agency to which the spot time inconsistency is applicable.Section 1032 preferably also lists the pertinent data fields for theapplicable final buy item and applicable invoice item (preferably thefields shown in FIGS. 4 and 5). Display section 1052 preferablyidentifies the tolerance (if any) that is built into the final buyitem's time range, and section 1054 preferably identifies the timedifferential between the invoice item and the final buy item (takinginto consideration the tolerance 1052). From this data and from anyother guidelines that may be in place for processing such exceptions(e.g., instructions from a client as to how to handle such anexception), the user can choose to undertake any of a plurality ofoptions, which preferably include the options set forth above inconnection with buttons 1010, 1006, and 1008.

FIG. 8( f) depicts a preferred GUI 1060 for handling a “spot dateinconsistency” exception which occurs when the invoice item's “spotdate” data does not fall within the range of its counterpart final buyitem's “buy dates” data range. GUI 1060 preferably includes a displaysection 1032 that identifies the media property, client, and advertisingagency to which the spot time inconsistency is applicable. Section 1032preferably also lists the pertinent data fields for the applicable finalbuy item and applicable invoice item (preferably the fields shown inFIGS. 4 and 5). Display section 1062 preferably identifies the datedifferential between the invoice item and the final buy item. From thisdata and from any other guidelines that may be in place for processingsuch exceptions (e.g., instructions from a client as to how to handlesuch an exception), the user can choose to undertake any of a pluralityof options, which preferably include the options set forth above inconnection with buttons 1010, 1006, and 1008.

It is worth noting that the GUIs of FIGS. 8( a)-(f) need not list only asingle exception. A practitioner of the present invention can alsodesign one or more of these GUIs such that a plurality of the applicableexception items for the selected media property/client/ advertisingagency conditions are listed. It is also worth noting that the GUIs ofFIGS. 8( a)-(f) may also include a user action button that is effectiveto allow the user to pay a user-specified amount for a spot thattriggered an exception handling condition, thereby allowing for partialpayments of disputed invoice items. In such a case, a field on the GUIor an additional GUI could be used through which the user could enterthis partial payment amount. Upon entry of such a partial paymentamount, the running total that represents the amount to be paid to themedia property can preferably be increased by the partial payment amountthat was entered by the user.

Returning to FIG. 6, at step 612, any items that were approved for fullpayment during the exception handling process and that do not requirefurther action from the media property (such as to approve a creditrequest) are flagged as approved for full payment. At step 614, adetermination is made as to whether all of the items listed in thesubject invoice have been appropriately reconciled with final buy items(either exactly matched or approved for payment as a result of theexception handling process). If the answer to that question is yes, theprocess preferably proceeds to step 608. If the answer to that questionis no, then at step 616, one or more messages are preferablyelectronically communicated to the media property to request action fromthe media property on the disputed invoice items, and payment on thesubject invoice is placed on hold (step 618).

As a result of step 616, the media property can expect to receive one ormore messages requesting action on a disputed invoice item. FIG. 9depicts an exemplary GUI 900 that could be presented on the computerscreen of a media property employee that lists received messages aboutdisputed invoice items. Section 902 of GUI 900 serves as an inbox forsuch received messages. By way of example, each received message can beidentified in a row 904 of section 902 by the date/time of receipt, thename of the applicable advertising agency for the disputed advertisementspot, the name of the applicable advertiser for the disputedadvertisement spot, the invoice number for the disputed advertisementspot, the invoice date for the disputed advertisement spot, and amessage code or short text section that briefly summarizes the nature ofthe dispute. To review a message that is listed in section 902, the usercan select the review button 906 corresponding to that message.

Upon selection of a review button 906, a GUI such as the ones shown inFIGS. 10( a) and 10(b) will be displayed. FIG. 10( a) depicts a GUI 1000that would be displayed after the user has selected a message relatingto a credit request arising from an invoice item that is disputed due toa spot cost inconsistency. GUI 1000 preferably includes a section 1002that identifies the applicable advertising agency and advertiser as wellas the pertinent final buy and invoice data in dispute. Section 1004preferably displays the cost differential between the final buy and theinvoice and section 1006 preferably displays the requested creditamount. The user can then approve the requested credit via selection ofbutton 1010 or reject the requested credit via selection of button 1012.If the user approves of the requested credit, then that final buyitem-invoice item pair will be deemed reconciled. If not, alternativemeans will preferably be employed to resolve the dispute (such astelephone calls, etc.) as payment the subject invoice will remain onhold.

FIG. 10( b) depicts a GUI 1020 that would be displayed after the userhas selected a message relating to a invoice item for which payment hasbeen rejected due to a spot time inconsistency. GUI 1020 preferablyincludes a section 1002 that identifies the applicable advertisingagency and advertiser as well as the pertinent final buy and invoicedata in dispute. Section 1022 preferably displays the allowed tolerancebetween the final buy's time range and the spot time identified on theinvoice. Section 1024 preferably displays the how far outside thistolerance the actual spot time on the invoice fell. The user can thenapprove the requested invoice item rejection via selection of button1026 or refuse the invoice rejection via selection of button 1028. Ifthe user approves of the rejection, then that final buy item-invoiceitem pair will be deemed reconciled. If not, alternative means willpreferably be employed to resolve the dispute (such as telephone calls,etc.) as payment on the subject invoice will remain on hold. Returningto FIG. 6, at step 620, the process will check to see if the mediaproperty has agreed to all of the user actions requested as a result ofthe exception handling process for the subject invoice. Essentially,this step operates to determine whether all of the invoice items for thesubject invoice have been appropriately reconciled. If the answer is no,then payment on the subject invoice will remain on hold (step 618). Ifthe answer is yes, then at step 622, instructions for payment of thesubject invoice for the approved amount are communicated to the NPsystem 108, less any applicable discounts for prompt payment. As withstep 608, these payments instructions will preferably interface with theNP software on computer system 108 to effectuate payment from theaccount on the approved adjusted invoice.

Therefore, using the preferred embodiment, invoices from mediaproperties for advertising services can be quickly and accuratelyreconciled. Furthermore, the account receivable time for such invoicescan be drastically reduced because payment on such invoices can bedelivered to media properties in near real-time after successfulreconciliation, thereby benefiting media properties by providing mediaproperties with money owed to them sooner rather than later.

While the present invention has been described above in relation to itspreferred embodiment, various modifications may be made thereto thatstill fall within the invention's scope, as would be recognized by thoseof ordinary skill in the art. For example, while the preferredembodiment described in connection with FIG. 6 operates where payment ismade on a monthly invoice-by-invoice basis, it should be noted that thesystem can also be configured to pay media properties on an invoice itemby invoice item basis (wherein payment of a invoice that lists 100 spotswould not be held up due to a dispute over 2 or 3 spots). With such aninvoice item, as each invoice item is reconciled with a final buy item,payment can be authorized and remitted for the cost of that invoice item(less any applicable discounts). Further still, it is worth noting thatthe invoices need not be monthly; other invoicing intervals could beused such as weekly, daily, bimonthly, etc. Such modifications to theinvention will be recognizable upon review of the teachings herein. Assuch, the full scope of the present invention is to be defined solely bythe appended claims and their legal equivalents.

What is claimed is:
 1. A system for auditing an advertising agency toevaluate how the agency performed in executing an advertising plan onbehalf of a company, the system comprising: a processor; and a memory;and wherein the processor and memory are configured to: receiveadvertising plan data, the advertising plan data describing anadvertising plan for a company; receive buy data in a plurality ofdifferent formats, the received buy data comprising a plurality of buyitems from a plurality of advertising agencies, each buy itemcorresponding to an advertisement spot request that was placed by anadvertising agency with a media property on behalf of a company, whereinthe received buy data comprises a member of the group consisting of (1)original buy data comprising a plurality of original buy items, (2)final buy data comprising a plurality of final buy items, and (3) actualbuy data comprising a plurality of actual buy items; generate commonlyformatted data by converting the received buy data to a common format,the commonly formatted data comprising a plurality of data fieldsrepresentative of the plurality of buy items; compare the advertisingplan data with the commonly formatted data representative of the buyitems; and generate report data indicative of an extent to which the buyitems satisfy the advertising plan data based on the comparisonoperation.
 2. The system of claim 1 wherein the received buy datacomprises actual buy data, wherein the advertising plan data comprisesdata representative of a target amount of exposure for an advertisingcampaign by the company, and wherein the processor and memory arefurther configured to: obtain exposure data for the actual buy items inthe actual buy data; perform the comparison operation by comparing theobtained exposure data with the target amount of exposure from theadvertising plan data; and perform the report data generation operationby generating the report data such that the report data is indicative ofan extent to which the obtained exposure data for the actual buy itemssatisfied the target amount of exposure from the advertising plan data.3. The system of claim 2 wherein the exposure data comprises a member ofthe group consisting of Nielsen television ratings and Arbitron radioratings.
 4. The system of 2 wherein the processor and memory are furtherconfigured to: associate the actual buy items with the obtained exposuredata corresponding thereto; and store the commonly formatted datarepresentative of the actual buy items associated with the obtainedexposure data in a database as posted buy data.
 5. The system of claim 4wherein the received buy data further comprises final buy data, andwherein the processor and memory are further configured to: compare thecommonly formatted final buy data with the posted buy data; generatedata indicative of an extent to which a plurality of the fields of theposted buy data match up with a plurality of the fields of the commonlyformatted final buy data based on the comparison operation between thefinal buy data and the posted buy data; and generate posted buy-to-finalbuy report data based on the generated data resulting from thecomparison operation between the final buy data and the posted buy data,the generated posted buy-to-final buy report data being indicative of anextent to which the advertisement spots of the posted buy datacorrespond to the advertisement spots of the final buy data.
 6. Thesystem of claim 5 wherein each of at least a plurality of the buy itemspresent in the received buy data comprises a data field pertaining to anaspect of the buy item and populated with coded data, the buy data forat least two of the advertising agencies having coded data for the datafield that are coded in different formats, and wherein the processor andmemory are further configured to: convert the coded data for each of thereceived buy items to coded data of a standardized coding format.
 7. Thesystem of claim 1 wherein each of at least a plurality of the buy itemspresent in the received buy data comprises a data field pertaining to anaspect of the buy item and populated with coded data, the buy data forat least two of the advertising agencies having coded data for the datafield that are coded in different formats, and wherein the processor andmemory are further configured to: convert the coded data for each of thereceived buy items to coded data of a standardized coding format.
 8. Thesystem of claim 7 wherein the processor and memory are furtherconfigured to: store a data table in the memory, the data table defininga mapping between coded data present in the data field of the receivedbuy items and the coded data of the standardized coding format; andperform the conversion operation by converting the coded data for eachof the received buy items to the coded data of the standardized codingformat based on the data table.
 9. The system of claim 8 wherein thedata table comprises a plurality of mapping records, each mapping recordcomprising a plurality of data table fields, the data table fieldscomprising: a first field for data representative of an identifier for asoftware package used by an advertising agency to generate buy data; asecond field for data representative of a data value for the coded datain the data field of the received buy items; and a third field for datarepresentative of a data value for the coded data of the standardizedcoding format corresponding to the data value for the coded data in thedata field of the received buy items for that mapping record; andwherein the processor and memory are further configured to perform theconversion operation by, for each of a plurality of buy items in thereceived buy data: determining a software package used by theadvertising agency to generate the data for that buy item; searching thedata table; determining whether a mapping record corresponding to thedetermined software package and the coded data in the data field forthat buy item is present in the data table based on the searchoperation; and based at least in part on a determination that such amapping record is present in the data table, replacing the coded data inthe data field for that buy item with the data value from the thirdfield of that mapping record.
 10. The system of claim 9 wherein theprocessor and memory are further configured to perform the conversionoperation by, based at least in part on a determination that a mappingrecord corresponding to the determined software package and the codeddata in the data field for that buy item is not present in the datatable: providing a user interface for display to a user; receiving userinput through the user interface corresponding to the data value to beused as the coded data of the standardized format for that buy item;replacing the coded data in the data field for that buy item with thedata value of the received user input; and updating the data table witha new mapping record that associates the determined software package forthat buy item with the coded data in the data field for that buy itemand the data value of the received user input.
 11. The system of claim 7wherein the data field comprises a daypart code field.
 12. The system ofclaim 1 wherein the received buy data comprises original buy data. 13.The system of claim 1 wherein the received buy data comprises final buydata.
 14. The system of claim 1 wherein the received buy data comprisesactual buy data.
 15. A computer-implemented method of auditing anadvertising agency to evaluate how the agency performed in executing anadvertising plan on behalf of a company, the method comprising:receiving advertising plan data, the advertising plan data describing anadvertising plan for a company; receiving buy data in a plurality ofdifferent formats, the received buy data comprising a plurality of buyitems from a plurality of advertising agencies, each buy itemcorresponding to an advertisement spot request that was placed by anadvertising agency with a media property on behalf of a company, whereinthe received buy data comprises a member of the group consisting of (1)original buy data comprising a plurality of original buy items, (2)final buy data comprising a plurality of final buy items, and (3) actualbuy data comprising a plurality of actual buy items; generating commonlyformatted data by converting the received buy data to a common format,the commonly formatted data comprising a plurality of data fieldsrepresentative of the plurality of buy items; comparing the advertisingplan data with the commonly formatted data representative of the buyitems; and generating report data indicative of an extent to which thebuy items satisfy the advertising plan data based on the comparing step;and wherein the method steps are performed by a processor.
 16. Themethod of claim 15 wherein the received buy data comprises actual buydata, wherein the advertising plan data comprises data representative ofa target amount of exposure for an advertising campaign by the company,the method further comprising: the processor obtaining exposure data forthe actual buy items in the actual buy data; and wherein the comparingstep comprises the processor comparing the obtained exposure data withthe target amount of exposure from the advertising plan data; andwherein the report data generating step comprises the processorgenerating the report data such that the report data is indicative of anextent to which the obtained exposure data for the actual buy itemssatisfied the target amount of exposure from the advertising plan data.17. The method of claim 16 wherein the exposure data comprises a memberof the group consisting of Nielsen television ratings and Arbitron radioratings.
 18. The method of 16 further comprising: the processorassociating the actual buy items with the obtained exposure datacorresponding thereto; and the processor storing the commonly formatteddata representative of the actual buy items associated with the obtainedexposure data in a database as posted buy data.
 19. The method of claim18 wherein the received buy data further comprises final buy data, themethod further comprising: the processor comparing the commonlyformatted final buy data with the posted buy data; generating dataindicative of an extent to which a plurality of the fields of the postedbuy data match up with a plurality of the fields of the commonlyformatted final buy data based on the step of comparing the commonlyformatted final buy data with the posted buy data; and generating reportdata based on the generated data resulting from the step of comparingthe commonly formatted final buy data with the posted buy data, thegenerated report data being indicative of an extent to which theadvertisement spots of the posted buy data correspond to theadvertisement spots of the final buy data.
 20. The method of claim 19wherein each of at least a plurality of the buy items present in thereceived buy data comprises a data field pertaining to an aspect of thebuy item and populated with coded data, the buy data for at least two ofthe advertising agencies having coded data for the data field that arecoded in different formats, the method further comprising: the processorperforming the converting step by converting the coded data for each ofthe received buy items to coded data of a standardized coding format.21. The method of claim 15 wherein each of at least a plurality of thebuy items present in the received buy data comprises a data fieldpertaining to an aspect of the buy item and populated with coded data,the buy data for at least two of the advertising agencies having codeddata for the data field that are coded in different formats, the methodfurther comprising: the processor performing the converting step byconverting the coded data for each of the received buy items to codeddata of a standardized coding format.
 22. The method of claim 21 furthercomprising: the processor storing a data table in a memory, the datatable defining a mapping between coded data present in the data field ofthe received buy items and the coded data of the standardized codingformat; and wherein the converting step comprises the processorconverting the coded data for each of the received buy items to thecoded data of the standardized coding format based on the data table.23. The method of claim 22 wherein the data table comprises a pluralityof mapping records, each mapping record comprising a plurality of datatable fields, the data table fields comprising: a first field for datarepresentative of an identifier for a software package used by anadvertising agency to generate buy data; a second field for datarepresentative of a data value for the coded data in the data field ofthe received buy items; and a third field for data representative of adata value for the coded data of the standardized coding formatcorresponding to the data value for the coded data in the data field ofthe received buy items for that mapping record; and wherein theconverting step further comprises the processor, for each of a pluralityof buy items in the received buy data: determining a software packageused by the advertising agency to generate the data for that buy item;searching the data table; determining whether a mapping recordcorresponding to the determined software package and the coded data inthe data field for that buy item is present in the data table based onthe searching step; and based at least in part on a determination thatsuch a mapping record is present in the data table, replacing the codeddata in the data field for that buy item with the data value from thethird field of that mapping record.
 24. The method of claim 23 whereinthe converting step further comprises: the processor, based at least inpart on a determination that a mapping record corresponding to thedetermined software package and the coded data in the data field forthat buy item is not present in the data table: providing a userinterface for display to a user; receiving user input through the userinterface corresponding to the data value to be used as the coded dataof the standardized format for that buy item; replacing the coded datain the data field for that buy item with the data value of the receiveduser input; and updating the data table with a new mapping record thatassociates the determined software package for that buy item with thecoded data in the data field for that buy item and the data value of thereceived user input.
 25. The method of claim 21 wherein the data fieldcomprises a daypart code field.
 26. The method of claim 15 wherein thereceived buy data comprises original buy data.
 27. The method of claim15 wherein the received buy data comprises final buy data.
 28. Themethod of claim 15 wherein the received buy data comprises actual buydata.
 29. A computer program product for auditing an advertising agencyto evaluate how the agency performed in executing an advertising plan onbehalf of a company, the computer program product comprising: executableprogram code resident on a non-transitory computer-readable storagemedium, the executable program code comprising a plurality of codesegments executable by a processor, the code segments configured to:receive advertising plan data, the advertising plan data describing anadvertising plan for a company; receive buy data in a plurality ofdifferent formats, the received buy data comprising a plurality of buyitems from a plurality of advertising agencies, each buy itemcorresponding to an advertisement spot request that was placed by anadvertising agency with a media property on behalf of a company, whereinthe received buy data comprises a member of the group consisting of (1)original buy data comprising a plurality of original buy items, (2)final buy data comprising a plurality of final buy items, and (3) actualbuy data comprising a plurality of actual buy items; generate commonlyformatted data by converting the received buy data to a common format,the commonly formatted data comprising a plurality of data fieldsrepresentative of the plurality of buy items; compare the advertisingplan data with the commonly formatted data representative of the buyitems; and generate report data indicative of an extent to which the buyitems satisfy the advertising plan data based on the comparisonoperation.